On 24/01/2019 18:26, Christopher Schultz wrote:
> Mark,
>
> On 1/23/19 16:55, VP Brand wrote:
>> On 23/01/2019 21:48, bugzi...@apache.org wrote:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62912
>>>
>>> --- Comment #14 from Mark Thomas <ma...@apache.org> --- Created
>>> attachment 36389 -->
>>> https://bz.apache.org/bugzilla/attachment.cgi?id=36389&action=edit
>>>
>>>
> Tomcat 9 patch to retain app provided content-type
>>>
>>> The application provided content-type is only retained if no
>>> charset is present.
>>>
>
>> Thoughts on applying this patch to Tomcat 9?
>
>> Pros: It allows apps to work with both user agents that require
>> spaces and user agents that require no spaces
>
>> Cons: The switch to passing through the app provided value may
>> break some user agents and an app change would be required to fix
>> it.
>
>> The risk looks to be very low but so is the scale of the problem
>> this fixes. One bug report in a little over 8 years suggests this
>> is an issue for a small minority of users.
>
>> If anything, I am leaning towards applying the patch. Thoughts?
>
> This might be a rat-hole of a question, but why are we implementing
> the same logic in two different places? o.a.coyote.Response and
> o.a.catalina.connector.Response? Can we get away with implementing
> this in only one place or the other?
Maybe. Some svn archaeology would probably be required to figure out why
it was implemented this way and if that reason was still valid.
> Related: is this code-comment from o.a.coyote.Response#containsHeader
> accurate?
Yes.
Mark
>
> /**
> * Does the response contain the given header.
> * <br>
> * Warning: This method always returns <code>false</code> for
> Content-Type
> * and Content-Length.
> *
> * @param name The name of the header of interest
> *
> * @return {@code true} if the response contains the header.
> */
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
