[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #16 from Mark Thomas --- Back-ported in: - 9.0.x for 9.0.47 onwards - 8.5.x for 8.5.67 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Mark Thomas --- Applied to master for 10.0.0-M5 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
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 --- Created
>>> attachment 36389 -->
>>> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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.
> *
> * Warning: This method always returns false 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
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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 --- Created
>> attachment 36389 -->
>> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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?
Related: is this code-comment from o.a.coyote.Response#containsHeader
accurate?
/**
* Does the response contain the given header.
*
* Warning: This method always returns false 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
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxKA0AACgkQHPApP6U8
pFg1dw//Vhfz1W4MLcuZ09VIxCHPTiAFwNqqfQifkWDVmndsOmqsDX+BF3LBkhOf
50n/7Hk8X9a39NJ49v7m+FivYCN8rEAhc2DGLXY3SNlxrR54CpJnMryvZgulGC5U
2CiGSWpL3OBmyW4FggWu/RnzU1xKwvtc9kBInIXn1Zh0LsaL1C/Dx3evpdKF+YLi
apft0km2757khgYsq18D4VOs7pcBpQxogwYLcHKQ56ZWJAO8+aSUcpfuemLcVgnM
UH0es2hQF6RYWUf97e0Eu+f/yUcGx2koWLa2/+vO+EnjG4n0t/+/AmOBKZ1zcLeK
I4j6ONtlaOpRbd8px56V+ZR86ymYB5KzQkYW5HNjuzh+GdUw5L95vDtXfVCItopK
PtBi0k6GeDKuYnoKYBlhv1P0hqx7ywWwv1m2NrTOkVlrhB/DL3ocdrhNpySTSJe1
gjc6TiafLZvdlqFBvAR/HnIz6uY/AVJI3VXmhl/CPpijYub1Cf6QhjNYTUzOtyJL
h2jImB4irsal0+0jaqbCe/fo2YPtPlzkWx5ci70cRdbAY85In0sKa3ygEfGuEYhD
G6UDWng5vYTp2HX6VlPwX8zON7WUFMpCJX/oDxEeZF7NSYQu8xgBTuTpgveOVrv3
r8EAZcQc62jm9xxPM7Q7goPwSF0auCB4zHBMUxhcTgqD3h1o16w=
=qOBc
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
On 23/01/2019 22:42, Igal Sapir wrote: > On 1/23/2019 1:56 PM, Mark Thomas 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 --- Created attachment 36389 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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? > > It looks safe to me. > > While reviewing the code I noticed the use of a String[] instead of a > simple class [1], which would make the code much more readable and more > maintainable. I have to admit that I reviewed it online on GitHub, it > is probably not as bad in an IDE. > > Would it make sense for me to refactor it? The new class can be > internal, possibly package private. I can't remember why I did it that way. It might have been related to GC/performance overhead. It would be worth checking the impact of any change. It might just have been that a String array was less code. The class will need to be public since it will be used by multiple packages. OK, we could use an interface but really does start to look like over engineering. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
On 1/23/2019 1:56 PM, Mark Thomas 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 --- Created attachment 36389 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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? It looks safe to me. While reviewing the code I noticed the use of a String[] instead of a simple class [1], which would make the code much more readable and more maintainable. I have to admit that I reviewed it online on GitHub, it is probably not as bad in an IDE. Would it make sense for me to refactor it? The new class can be internal, possibly package private. Best, Igal [1] https://github.com/apache/tomcat/blob/trunk/java/org/apache/tomcat/util/http/parser/MediaTypeCache.java#L41 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
On 23/01/2019 21:55, VP Brand wrote: Sorry. No idea why my mail client picked that senders address. I must have hit the wrong button. Mark > 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 --- >> Created attachment 36389 >> --> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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? > > Mark > > - > 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
Re: [Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
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 --- > Created attachment 36389 > --> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=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? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #14 from Mark Thomas --- Created attachment 36389 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36389=edit Tomcat 9 patch to retain app provided content-type The application provided content-type is only retained if no charset is present. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 Mark Thomas changed: What|Removed |Added Severity|critical|enhancement --- Comment #13 from Mark Thomas --- Moving this to an enhancement. The bug is in the user agent, not Tomcat. Given that: - we have examples of broken clients that fail both with a space and without a space - both with a space and without a space a spec compliant If we pick one option and hard-code it, experience tells us that it will break for someone at some point. While we could simply respond "Fix the broken user agent" I think Chris's idea is worth exploring. Assuming the code is minimal, it should be doable for Tomcat 10. The bigger question is whether the fix is considered safe enough for back-port. I'll put together a patch and start a discussion on the dev list. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912
--- Comment #12 from romain.manni-bucau ---
Hi guys,
isn't it possible to fix this issue since the space has this comment
(org.apache.tomcat.util.http.parser.MediaType#toString):
> // Workaround for Adobe Read 9 plug-in on IE bug
> // Can be removed after 26 June 2013 (EOL of Reader 9)
> // See BZ 53814
Guess we are after 2013 so maybe time to drop it?
Since space or not is valid from a spec perspective and the servlet spec let
the developper responsible to set the right content type (5.2 of servlet 4)
then the dev should be the one able to decide to use a space or not. For the
case tomcat has to build the content type (character encoding usage) I guess
the delimiterString (";" or "; ") can be configured?
Romain
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #11 from Franos --- Hello, I have looked at that. Thanks. My worry is that it's scheduled for Tomcat 10. We really need that on Tomcat 8.5.x and 9.x branches. Best Regards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #10 from Christopher Schultz --- Note that this is being discussed on the dev list a bit. See r1846691. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #9 from Franos --- Hello, > Okay, so we have some clients that vitally depend upon the space being added > and other clients that vitally depend upon the space *not* being added. Why > should your clients win over the others? I think that in most cases the provider of a server side solution validates their developments with a fixed list of clients (eg list of User-Agent s). In such case we can control the response (HTTP header included) to be sent to those clients depending of the value read from the request in the User-Agent HTTP header. So why Tomcat is changing a value we have set at server side and we know it works with the list of User-Agent s we want to support ? More, in the tests I have performed, if the content sent to the client is character based, Tomcat appends automatically ";charset=ISO-8859-1", for example, with no space. So why sometimes, we have space and sometimes we haven't ? > The real question is "why is Tomcat bothering to re-format the content-type > header when it does not have to do so?". Yes, this is indeed the question I have. > I could see an argument for a "don't mutate content-type headers when no > charset is present", but that's not what you asked for. So consider I ask for that. Best Regards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #8 from Mark Thomas --- Chris, you make a good point about not mutating the value unnecessarily. I did look briefly at what would be involved. It looks simple to do. My concern is that it has broadly the same potential to trigger regressions as removing the space - although at least ones that could be fixed by an application change. Probably something else to consider for Tomcat 10 alongside removing the space. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #7 from Christopher Schultz --- (In reply to Franos from comment #6) > What is quite disturbing to me is: > - space character is optional as you mentioned > - so why if, in the servlet code, you set a Content-Type with a ; > character >and no space after, even if the space character is optional, you add > this >one just after the ; This is being added because the header you are adding must be parsed by Tomcat *just in case there is a character set present* so it can be specially-handled. Since Tomcat parses the content-type (as set by the application), it can re-assemble the content-type header from the parsed values. > Yes you are right when saying it could be fixed at client-side but sometimes > there are some situations where some client versions couldn't be updated. > This is our case: those client versions are already deployed on the field > and no easy way to update them unfortunately. Okay, so we have some clients that vitally depend upon the space being added and other clients that vitally depend upon the space *not* being added. Why should your clients win over the others? > So is there any way to have a Tomcat (hidden) setting, in order to not have > a space character after a ; character. The real question is "why is Tomcat bothering to re-format the content-type header when it does not have to do so?". I could see an argument for a "don't mutate content-type headers when no charset is present", but that's not what you asked for. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #6 from Franos --- Hello Thomas, I try to figure out what you're saying. If I have well understood: - If, in the Content-Type value you have a semi-column followed by a string, you can have or not (because you mention it is optional) after the semi-column a space character, right ? - The current Tomcat implementation is to add a space character after the semi-column in any case. What is quite disturbing to me is: - space character is optional as you mentioned - so why if, in the servlet code, you set a Content-Type with a ; character and no space after, even if the space character is optional, you add this one just after the ; Yes you are right when saying it could be fixed at client-side but sometimes there are some situations where some client versions couldn't be updated. This is our case: those client versions are already deployed on the field and no easy way to update them unfortunately. So is there any way to have a Tomcat (hidden) setting, in order to not have a space character after a ; character. Best Regards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #4 from Mark Thomas --- I'll be clearer. There is no Tomcat bug here. Tomcat's response is consistent with what the Servlet requested and compliant with RFC 7201. You haven't explained what the problem is but the working assumption is that the user agent (client) you are using can't handle the space Tomcat inserts. That is a bug in the user agent and should be fixed there. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #5 from Franos --- Created attachment 36262 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36262=edit The war to be deployed Then target http://localhost:8080/MyServletReturningContentTypeWithComma/test -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 --- Comment #3 from Franos --- Hello, I can provide you a test case if you want ? Just tell me. Best Regards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912
--- Comment #2 from Franos ---
Hello Mark,
Not sure to have really understand what you said.
You talk about charset but the content I want to deliver to the client is a
binary content.
My disappointment is that I set a content type for the response that seems to
be modified by Tomcat. Indeed, I set it to
"application/xxx.yyy-data;version=1.0" and the client get a Content-Type set
to "application/xxx.yyy-data; version=1.0": a space character has been
introduced right after the ; character.
I have tested this with different User-Agent s.
Curl:
Request headers:
User-Agent: curl/7.40.0
Host: localhost:8080
Accept: */*
Response headers:
HTTP/1.1 200
Content-Type: application/xxx.yyy-data; version=1.0
Transfer-Encoding: chunked
Date: Thu, 15 Nov 2018 15:16:06 GMT
Firefox:
Request headers:
User-Agent: Mozilla/5.0 (Windows NT 6.1; W…) Gecko/20100101 Firefox/62.0
Host: localhost:8080
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Response headers:
HTTP/1.1 200
Content-Type: application/xxx.yyy-data; version=1.0
Transfer-Encoding: chunked
Chrome:
Request headers:
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Host: localhost:8080
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Response headers:
HTTP/1.1 200
Content-Type: application/xxx.yyy-data; version=1.0
Transfer-Encoding: chunked
Date: Thu, 15 Nov 2018 16:20:20 GMT
So whatever the User-Agent used, the Content-Type is application/xxx.yyy-data;
version=1.0 (with a space character right after the ; character) whereas I have
written in my servlet code
response.setContentType("application/xxx.yyy-data;version=1.0"); (no space
character after the ; character).
Is it clearer ?
Best Regards.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62912] Tomcat adds a space character in the Content-Type header if this one has a ; character right after
https://bz.apache.org/bugzilla/show_bug.cgi?id=62912 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Tomcat has to separate any charset from the provided content-type and store the charset and content-type (minus charset) separately. Extraction of the charset can be tricky. Historically there were a few bugs in this area until we switched to using a full parser. Similarly, generating content-type minus the charset had difficulties. Therefore, this value is generated by the parser from the constituent parts. >From RFC 7231: Content-Type = media-type media-type = type "/" subtype *( OWS ";" OWS parameter ) type = token subtype= token White space after the semi-colon is optional but valid. If a user-agent is unable to parse this correctly then that is a bug in the user-agent, not in Tomcat. Normally, I'd close bugs like this as WONTFIX but recalling a similar issue I dug into the history a little: bug 53814 bug 52811 The original intention was not to include a space after the semi-colon. It was added as a work-around for a popular but buggy client (Adobe Reader 9 on IE). It should be possible to remove the work-around but bitter experience makes me fear what else this might break. I'd like to remove the work-around, mainly as it reduces (very marginally) the network traffic per request and removes a few lines of code but that is probably something to consider for Tomcat 10 given the possibility of user-agent breakage. At this point, fixing the bug in the user-agent parsing this header so it can handle the header with or without the optional white space looks like the best solution. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
