dcsimg
"Content-Type" HTTP header effects reading streams in Java1.3 - Why?
0 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Stuart_Sim
Posted On:   Thursday, January 16, 2003 04:55 AM

Hi, We are currently upgrading our Java servlet based application from Java 1.2 to Java 1.3.1_04. We have found that this upgrade has had a major effect on how java interprets HTTP requests. We receive FORM and stream POSTS in a number of Character Encodings, ASCII, ISO-8859-1, UTF-8 and Shift-JIS. Under Java 1.2 we did not used to pay any attention to this or make any effort to convert from the encoding to Java’s internal Unicode format when reading in streams - everything just worked OK by default. However after installing the 1.3 JRE we have found that unless we specifically convert between the character set being received and Unicode any non ASCII characters become corrupted. We have therefore spent some weeks going through the applica   More>>

Hi,

We are currently upgrading our Java servlet based application from Java 1.2 to Java 1.3.1_04. We have found that this upgrade has had a major effect on how java interprets HTTP requests. We receive FORM and stream POSTS in a number of Character Encodings, ASCII, ISO-8859-1, UTF-8 and Shift-JIS. Under Java 1.2 we did not used to pay any attention to this or make any effort to convert from the encoding to Java’s internal Unicode format when reading in streams - everything just worked OK by default. However after installing the 1.3 JRE we have found that unless we specifically convert between the character set being received and Unicode any non ASCII characters become corrupted.

We have therefore spent some weeks going through the application and “tightening up” all the conversions so that all switching between a specific character set and Unicode is now handled correctly. However we have not encountered another problem which seems to have been introduced by Java 1.3 .

Our servlet can receive two types of request, standard FORM POSTS with parameters that can be read using the getParameter(String) method and stream requests. To differentiate between the two we use the Request.getContentLength() method. Under Java 1.2 this would return –1 if the request was a standard FORM POST or a request length in Bytes if the request was a stream, REGARDLESS of the value of the “Content-Type” HTTP header. However under Java 1.3 if the “Content-Type” has a value of “application/x-www-form-urlencoded” (which is the default for standard Parameter FORM POSTs) Request.getContentLength returns -1 even if the POST is a stream. This is causing us major problems as we have a number of customers who post streams with this Content-Type and will be reluctant to change their systems. We have tried ignoring the content length and opening an input stream reader on the request anyway but this doesn’t work – it appears that Java (or our web server iPlanet 6.0 – though we think this not less likely to be the culprit) will not deal with the request as a stream in any way if it sees “application/x-www-form-urlencoded”.

We have searched through all the Java 1.3 release notes and docs to find some explanation of the changes that have obviously been made to Javas request handling in release 1.3 but have come up with nothing. Surely if sun decided to “tighten up” request handling in this way and so remove the backwards compatibility in this area surely they should have had the decency to tell us!!.

Can anyone else shed any light on this?.

Best Regards,

Stuart Sim

   <<Less
About | Sitemap | Contact