tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eirik √ėverby <>
Subject Re: Content-Type rewriting in jakarta-tomcat-connectors
Date Thu, 02 Dec 2004 11:25:39 GMT
Hi again,

Shapira, Yoav wrote:
> Hi,
>  >After upgrading from tomcat 4.1 to 5.0, a critical application here has
> It'd be a shame if the upgrade wasn't tested first in a test/QA
> environment ;(
>  >In 5.0.29, this comes out as
>  >
>  >Content-Type: application/xml;charset=utf-8
> It's also interesting that you chose a beta version of Tomcat, as
> opposed to a stable version, for such an important application.
> However, that's irrelevant to this discussion.
>  >However, the key here is that the connector (more specifically around
>  >line 520 in
>  >jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.ja
> va)
>  >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.
> So you've identified the specific location of the code you need to
> change.
>  >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,
> how
>  >are the chances of seeing this 'fixed' in an upcoming release of Tomcat
>  >5.0.x?
> In an upcoming release, the chances are good.  But we just released
> 5.0.30 so 5.0.31 won't happen in the next few days.  So don't hold your
> breath, especially since it sounds like this is affecting a production
> instance.
> You could patch only the Response class, compile it, and put it in
> server/classes (which has priority over server/lib by definition), and
> that way fix the problem for your immediate needs in a custom but
> relatively effortless manner.

Until now I have simply placed the tomcat-coyote.jar file into 
server/lib; this has worked fine. However, when following your 
suggestion (placing the modified Response.class in server/classes), the 
old behavior is seen again. It seems as if the server/classes directory 
is not included in the classpath used.
Any idea what I've missed?


> You could also consider a Filter-based approach that sets the encoding
> including a charset: that way the connector won't have to rewrite/append
> the charset for you at all.  And that way, your solution is portable and
> does not depend on a Tomcat release.
> As an aside, note that in general our implementation of these specs
> (HTTP, servlet, JSP) is stricter as Tomcat evolves.  There are a number
> of things that "worked" in Tomcat 4.x that may not work (or work the
> same) in 5.x, so complete testing is a good idea when doing this major
> version upgrade.
> Yoav Shapira
> This e-mail, including any attachments, is a confidential business 
> communication, and may contain information that is confidential, 
> proprietary and/or privileged.  This e-mail is intended only for the 
> individual(s) to whom it is addressed, and may not be saved, copied, 
> printed, disclosed or used by anyone else.  If you are not the(an) 
> intended recipient, please immediately delete this e-mail from your 
> computer system and notify the sender.  Thank you.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message