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.
if (findBytes(connectionValueBC, Constants.CLOSE_BYTES) != -1) {
keepAlive = false;
} else if (findBytes(connectionValueBC,
Constants.KEEPALIVE_BYTES) != -1) {
In this specific case I said via curl: "Connection: close2" and it still
matched.
and on likely other spots. I believe they are wrong.
Yes, but. Is the cost of parsing that header (and any similar headers)
fully worth the benefit? The header parser is reasonably efficient so it
might be OK.
I'd suggest creating a BZ issue for this.
Will do!
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
