tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Change in behavior of parsing Content-Type header since TC 7.0.27
Date Tue, 26 Jun 2012 22:36:40 GMT
On 26/06/2012 23:26, Au, Leon wrote:
> On 6/25/12 9:19 AM, "Au, Leon" <leonau@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.

There is generally a strong reluctance amongst the Tomcat committers to
add workarounds into Tomcat for broken third-party software.

Exceptions have been made in the past, but I don't see a strong enough
argument in this case at this point in time. That said, if the fix is
trivial and another committer wants to fix this I'm unlikely to stand in
their way.

Mark

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


Mime
View raw message