On 6/25/12 9:19 AM, "Au, Leon" <leo...@amazon.com> wrote: >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
Bumping since there is talk of cutting 7.0.29 soon and I'd like to see if we should consider this a regression that might get fixed or if we should just work around this with each client we encounter that is affected as we find them. Leon --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
