Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41AE1042.7020607@unicore.no>
Date: Wed, 01 Dec 2004 19:41:06 +0100
From: =?ISO-8859-1?Q?Eirik_=D8verby?= <eirik@unicore.no>
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
MIME-Version: 1.0
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Subject: Re: Content-Type rewriting in jakarta-tomcat-connectors
References: <9C5166762F311146951505C6790A9CF801FC3982@US-VS1.corp.mpi.com>
In-Reply-To: <9C5166762F311146951505C6790A9CF801FC3982@US-VS1.corp.mpi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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 ;(

Well that's the thing.. It was tested, worked, but then the "other end" 
changed their stuff in a way that turned out to be incompatible. In any 
case, testing can always be better, and perhaps I should have hinted 
they should test with other Tomcat versions than 3.x and 4.x - so I 
accept partial responsibility here.. ;)

> 
> 
>>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.

I was actually of the impression that 5.0.29 was *not* a beta release; 
possibly because it is the only current version available in the FreeBSD 
ports tree. I was also advised by the developer of the webapp that 
5.0.29 had proven stable with their application, just like many previous 
releases of 5.0.x.
Weird though, that 5.5.x is not in the FreeBSD ports tree, but that's 
not a discussion for this list.

> However, that's irrelevant to this discussion.
Trueism.

> 
> 
>>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.

I have, and I have tested the change and found it to work. All 
prescribed test cases completed successfully.

> 
> 
>>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?
> 
> 
> 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.

But you are saying 5.0.31 or 5.0.32 or something along those lines might 
see the change? That's certainly more encouraging than 'never' or '7.x' 
or anything like that. I will anyhow not take this for granted, only use 
it as input to the discussion that will arise as to what path we choose 
from here.

> 
> 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.

That might, indeed, be a good way to do it. Extracting it from the 
tomcat-coyote.jar file after a build would be sufficient?

> 
> 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.

That's for the application developers to look into. I will certainly 
propose such an approach.

> 
> 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.

I have noticed, thanks..

And thanks for your input and time!

/Eirik


> 
> Yoav Shapira http://www.yoavshapira.com
> 
> 
> 
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org