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.

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.

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.

Mike,

Thanks for the update. This is very useful information.

Cheers,
Anton

FYI - after experiencing the same issues with Confluence behind a Resin server, the issue was fixed by changing mod_caucho to mod_proxy

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

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)

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