Am 2019-10-09 um 23:46 schrieb Michael Osipov:
Am 2019-10-09 um 23:23 schrieb Mark Thomas:
On 09/10/2019 22:03, Michael Osipov wrote:
Am 2019-10-09 um 19:08 schrieb Mark Thomas:
On 09/10/2019 16:58, Michael Osipov wrote:
Folks,
while working on an improvement for Http11Processor I have noticed
there
constructs:
if ((contentEncodingMB != null)
(contentEncodingMB.indexOf("gzip") != -1))
The parsing of this is much tighter on input. For output I think
this is
a reasonable trade-off. The worst that will happen is that Tomcat won't
compress something it might have been able to.
I agree on output, but there is at least on counter example:
// Check if browser support gzip encoding
MessageBytes acceptEncodingMB =
request.getMimeHeaders().getValue("accept-encoding");
if ((acceptEncodingMB == null)
|| (acceptEncodingMB.indexOf("gzip") == -1)) {
return false;
}
It would even accept "Accept-Encoding: figzip" as valid input.
That isn't there in 9.0.x. I wonder why the new CompressionConfig class
isn't being used in 8.5.x (that parses this correctly). I have a vague
recollection of backwards compatibility issues with the back-port but it
is worth revisiting that.
Checked CompressionConfig in master:
if (contentEncodingMB != null &&
(contentEncodingMB.indexOf("gzip") != -1 ||
contentEncodingMB.indexOf("br") != -1)) {
return false;
}
if ((acceptEncodingMB == null) ||
(acceptEncodingMB.indexOf("gzip") == -1)) {
return false;
}
don't look any better, do they?
Issue?
I guess, I need to spawn an issue anyway because of
https://tools.ietf.org/html/rfc7231#section-3.1.2.1:
"All content-coding values are case-insensitive ..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
