https://bz.apache.org/bugzilla/show_bug.cgi?id=62912
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
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
