We have a Servlet dispatcher that is deployed under TC 5.0.28. It employs SAAJ1.1 to generage SOAP Messages as part of content as response to HTTP POST requests. The dispatcher servlet, among other things, sets the headers with appropriate content-type and length. With any application based errors we create a SOAP Fault message, and set the headers (Content-type=text/xml; charset=utf-8), the appropriate Content-length header, and to be compatible with webservices SOAP Fault the HTTP error code to 500. Oddly, the Coyote Connector rewrites or dishonours the Content-type and resets to text/html as opposed to the intented value text/xml. This is error is consistently reproducible on all installations of 5.0.28. Without any SOAP fault messages where we set the return HTTP code to 200, the headers are preserved. That is, Content-type=text/xml is not altered. I do not see this on 4.1.29 or 5.0.2x, except on 5.0.28. Below is an example of what is returned: --> POST /caa/ HTTP/1.1 --> User-Agent: Scalix CAA/Ubermanager 1.0 --> Content-Type: text/xml; charset="utf-8" --> Content-Length: 458 --> SOAPAction: "" --> Cache-Control: no-cache --> Pragma: no-cache --> Host: verona.scalix.local:9090 --> Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 --> Connection: keep-alive --> --> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> --> <SOAP-ENV:Body> --> <scalix-caa:CAARequestMessage xmlns:scalix-caa="http://www.scalix.com/caa"> --> <ServiceType>scalix.res</ServiceType> --> <FunctionName>GetConsoleConfig</FunctionName> --> <Credentials id="12345"> --> <Identity name="sxadmin" passwd="sharks"/> --> </Credentials> --> </scalix-caa:CAARequestMessage></SOAP-ENV:Body></SOAP-ENV:Envelope> <-- HTTP/1.1 500 Internal Server Error <-- SOAPAction: "" <-- Content-Type: text/html;charset=utf-8 <-- Content-Length: 463 <-- Date: Tue, 11 Jan 2005 01:39:31 GMT <-- Server: Apache-Coyote/1.1 <-- Connection: close <-- <-- <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>CAA Service Error</faultstring><detail><scalix-caa:fault-details xmlns:scalix-caa="http://www.scalix.com/caa"><message>Failed to Authenticatecredentials for userid = sxadmin</message><errorcode>UM-1023</errorcode></scalix-caa:fault-details></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope> [Mon Jan 10 17:39:31 GMT-08:00 2005] Connection to 10.1.2.201:49815 closed.
Please submit a ready to test WAR.
We are encountering this bug also - we are using webMethods GLUE to generate SOAP packets. On Tomcat 4.x and Tomcat 5.0.x prior to 5.0.28 we have seen no problem. On 5.0.28 we are seeing our SOAP faults being sent with Content-Type: text/html, which is causing the client problems in handling the message.
Since I didn't get a test case ... Are you using sendError to set the 500 ? I think I see a possible problem with the algorithm in the error report valve (which is also inefficient in that particular situation).
I've committed code in the 5.5 CVS. Please test it if you can. The workaround, assuming I am right about the bug, is to commit the response (call flush on the reponse, for example).
No. We use HttpServletResponse.setStatus (HttpServletResponse.SC_INTERNAL_ERROR). As for the war file, I am in the middle of release and a bit swamped, but it is fairly reproducible. But a small servlet deployed under TC 5.0.28 returning the above and then setting MimeHeaders to add content-type, content-length should do the job.
This should be fixed in the Tomcat 5.5 CVS then.
I'm taking Remy's word on faith. If you test 5.5.9 and find it's still broken, feel free to reopen with the new data and a test case we can (hopefully) reproduce.