|
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 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
FYI - after experiencing the same issues with Confluence behind a Resin server, the issue was fixed by changing mod_caucho to mod_proxy
Mike,
Thanks for the update. This is very useful information. Cheers, 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. 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
In either case, if getting the .Net client to use the tomcat port directly is an option, this should bypass the issue. 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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