Issue Details (XML | Word | Printable)

Key: JRA-11515
Type: Bug Bug
Status: Resolved Resolved
Resolution: Not a bug
Priority: Major Major
Assignee: Unassigned
Reporter: Michael Cline
Votes: 2
Watchers: 3
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
JIRA

SOAP Response Content Type is 'text/plain' instead of 'text/xml'

Created: 11/Nov/06 08:25 PM   Updated: 27/Nov/08 07:34 PM
Component/s: Remote API (SOAP & XML-RPC)
Affects Version/s: 3.7 Beta 1
Fix Version/s: None

Time Tracking:
Not Specified

Environment: .NET 1.1 WebService Client
Issue Links:
Reference
 

Participants: Anton Mazkovoi [Atlassian], Brad Baker [Atlassian - JIRA BugMaster], Michael Cline, Michael McKeown, Michael McKeown and Yuen-Chi Lian [Atlassian]
Since last comment: 31 weeks, 1 day ago
Resolution Date: 27/Nov/08 07:34 PM
Labels:


 Description  « Hide
Header from WebService call to http://jira.atlassian.com/rpc/soap/jirasoapservice-v2 responds with

<HTTPHeaders>
<date>Sun, 12 Nov 2006 02:19:07 GMT</date>
<server>Apache/2.0.52 (Red Hat)</server>
<keep-alive>timeout=15, max=100</keep-alive>
<connection>Keep-Alive</connection>
<transfer-encoding>chunked</transfer-encoding>
<content-type>text/plain; charset=UTF-8</content-type>
</HTTPHeaders>

This causes a soap client to complain that the content type is supposed to be text/xml

Seems that this is the same issue as JRA-10743



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Yuen-Chi Lian [Atlassian] added a comment - 13/Nov/06 12:26 PM
Hello Michael,

I have tested this on http://jira.atlassian.com/rpc/soap/jirasoapservice-v2 (Content-Type: text/html) and http://jira.atlassian.com/rpc/soap/jirasoapservice-v2?wsdl (Context-Type: text/xml) using different clients without problem.

May I know which URL you're pointing to? The first one or the latter one? It seems like only .NET clients are facing this problem.

Cheers,
Yuen-Chi Lian


Michael Cline added a comment - 13/Nov/06 07:58 PM
I am pointing to:
http://jira.atlassian.com/rpc/soap/jirasoapservice-v2

the issue is only with the content-type of the message, the message is properly formatted. The HTTP Header sends the incorrect content-type. Perhaps only .NET webservices check for this content-type. I put a piece in the middle that does a string replace on content-type: text/plain with text/xml and the functionality works fine. Maybe it is a setting of the webserver rather than the Jira application.

Certainly doesn't work for .NET and other versions work fine (http://jira.codehaus.org/rpc/soap/jirasoapservice-v2)


Michael Cline added a comment - 13/Nov/06 08:00 PM
I get this message when I actually try to invoke a method, such as Login. The response is correct (with a sessionid) but the framework fails because of the content type

Michael McKeown added a comment - 22/Jun/07 06:22 AM
FYI - after experiencing the same issues with Confluence behind a Resin server, the issue was fixed by changing mod_caucho to mod_proxy

Anton Mazkovoi [Atlassian] added a comment - 24/Jun/07 08:18 PM
Mike,

Thanks for the update. This is very useful information.

Cheers,
Anton


Anton Mazkovoi [Atlassian] added a comment - 02/Jul/07 05:30 AM
We do use mod_caucho. The advantage is that the connections to the app-server are pooled, performance should be better, and that certain information is preserved from the request (e.g. when using mod_proxy the connecting host is always the proxy host, i.e. 127.0.0.1).

It looks like mod_caucho has a bug.


Michael McKeown added a comment - 22/Nov/07 05:00 PM
This issue also raises its head with Apache web server - seems there was a bug in mod_jk. See http://www.nabble.com/mod_jk---answers-from-appsrv-often-changes-'content-type'-from-text-xml-to-text-plain-t4736483.html for details.

In either case, if getting the .Net client to use the tomcat port directly is an option, this should bypass the issue.


Brad Baker [Atlassian - JIRA BugMaster] added a comment - 27/Nov/08 07:34 PM
This is not a bug in JIRA per se.

I have re-checked and we definitely respond with text/xml

Also jira.atlassian.com is no longer using mod_caucho or resin so this issue is now defunct.