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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
