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]

Reply via email to