tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Au, Leon" <leo...@amazon.com>
Subject Change in behavior of parsing Content-Type header since TC 7.0.27
Date Mon, 25 Jun 2012 16:19:37 GMT
Hi,

There was a recent change to how Tomcat handles the Content-Type response header in order
to address Bug #52811 (https://issues.apache.org/bugzilla/show_bug.cgi?id=52811)

We've noticed that this can cause issues with client code when parsing the response.  We traced
the issue to that fact that Tomcat now breaks apart the content type string and then reassembles
it. (http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/parser/AstMediaType.java?view=log)
 A space character before a 'boundary=' clause that would be part of the original content-type
string would be removed as a result.  For example, what used to be

Content-Type: multipart/related;type="text/xml"; boundary=MIME_boundary

Is now (since 7.0.27)

Content-Type: multipart/related;type="text/xml";boundary=MIME_boundary


Technically speaking, there’s nothing wrong with this and I think it follows the MIME standard
outlined in RFC-2045. (http://www.ietf.org/rfc/rfc2045.txt)

However, it does break clients that may be using libraries that are not so tolerant.  For
instance, the Ruby library soap4r fails to parse the response header in this case.  Would
it be possible for Tomcat to somehow retain spacing format from the original setContentType
call?

Thanks,

Leon

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message