You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Au, Leon" <le...@amazon.com> on 2012/06/25 18:19:37 UTC
Change in behavior of parsing Content-Type header since TC 7.0.27
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
Re: Change in behavior of parsing Content-Type header since TC 7.0.27
Posted by Mark Thomas <ma...@apache.org>.
On 26/06/2012 23:26, Au, Leon wrote:
> On 6/25/12 9:19 AM, "Au, Leon" <le...@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
Re: Change in behavior of parsing Content-Type header since TC
7.0.27
Posted by "Au, Leon" <le...@amazon.com>.
On 6/25/12 9:19 AM, "Au, Leon" <le...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org