Bug 33033 - 500 Internal Error and Content-Type not honored.
Summary: 500 Internal Error and Content-Type not honored.
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:Coyote (show other bugs)
Version: 5.0.28
Hardware: PC Windows XP
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2005-01-11 03:14 UTC by Jules Damji
Modified: 2005-07-22 14:59 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Jules Damji 2005-01-11 03:14:49 UTC
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

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
-->     <SOAP-ENV:Body>
-->         <scalix-caa:CAARequestMessage
-->             <ServiceType>scalix.res</ServiceType>
-->             <FunctionName>GetConsoleConfig</FunctionName>
-->         <Credentials id="12345">
-->             <Identity name="sxadmin" passwd="sharks"/>
-->         </Credentials>

<-- 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
Service Error</faultstring><detail><scalix-caa:fault-details
xmlns:scalix-caa="http://www.scalix.com/caa"><message>Failed to
Authenticatecredentials for userid =
[Mon Jan 10 17:39:31 GMT-08:00 2005] Connection to closed.
Comment 1 Remy Maucherat 2005-01-11 07:57:17 UTC
Please submit a ready to test WAR.
Comment 2 Chris Rimmer 2005-01-21 10:25:55 UTC
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.
Comment 3 Remy Maucherat 2005-01-21 13:27:54 UTC
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).
Comment 4 Remy Maucherat 2005-01-21 14:12:33 UTC
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).
Comment 5 Jules Damji 2005-01-21 19:38:42 UTC
No. We use HttpServletResponse.setStatus

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.
Comment 6 Remy Maucherat 2005-01-22 19:41:17 UTC
This should be fixed in the Tomcat 5.5 CVS then.
Comment 7 Yoav Shapira 2005-07-22 22:59:20 UTC
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.