Hi,
Follow-up: The same happens when using Tomcat stand-alone - i.e. no Apache and no jk.
/Eirik
Eirik Øverby wrote:
Hi,
no, it is not related at all to the oft-discussed UTF-8 issues.
This simply has to do with how the connector splits up the Content-Type string and then sews it together without adding a space after the ;.
/Eirik
Arnab Chakravarty wrote:
Eirik,
Does it have anything to do with UTF-8 encoding support (using different charsets - Chinese or Japanese) on jsp page and would break (not displaying the non-english characters) on tomcat 5.0.29.
Arnab
-----Original Message-----
From: Eirik Øverby [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 11:15 PM
To: [EMAIL PROTECTED]
Subject: Content-Type rewriting in jakarta-tomcat-connectors
Hi,
After upgrading from tomcat 4.1 to 5.0, a critical application here has stopped working as expected. Upon replying to incoming requests, it would usually spit out the following - just like the servlet says:
Content-Type: application/xml; charset=utf-8
In 5.0.29, this comes out as
Content-Type: application/xml;charset=utf-8
In the second variant, the space between the ; and the charset string is gone. This breaks a *very* important service that we provide for a rather large credit card company.
Without having studied RFCs and so on, I am pretty certain that it would be good coding-etiquette to have your app accept a Content-Type string with or without that space. Yes, I therefore know, it's their server - which sends the request to us - that has a lousy implementation.
However, the key here is that the connector (more specifically around
line 520 in
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java)
is rewriting the carefully-constructed Content-Type string in a way that 1: I didn't ask for and 2: wasn't done in 4.1.
Given that it is highly unlikely that anyone "at the other end" is going to do anything about this any time soon, and given that the solution is very trivial (add a space in that string composer in Response.java), how are the chances of seeing this 'fixed' in an upcoming release of Tomcat 5.0.x?
I really would rather not have to maintain my own source for Tomcat - I've spent the better part of the last 6 months trying to wrestle the application we are running out of a customized environment and into a standardized one; this would go head-on with that effort.. :(
Thanks for listening, /Eirik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]