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.

Mark


> 
>>>> 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: 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

Reply via email to