httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: keep-alive and vary in 304 responses
Date Wed, 10 Apr 2019 12:40:04 GMT


> Am 10.04.2019 um 14:07 schrieb Plüm, Rüdiger, Vodafone Group <ruediger.pluem@vodafone.com>:
> 
> 
> 
> 
> C2 General
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Yann Ylavic <ylavic.dev@gmail.com>
>> Gesendet: Mittwoch, 10. April 2019 14:04
>> An: httpd-dev <dev@httpd.apache.org>
>> Betreff: Re: keep-alive and vary in 304 responses
>> 
>> On Wed, Apr 10, 2019 at 1:03 PM Plüm, Rüdiger, Vodafone Group
>> <ruediger.pluem@vodafone.com> wrote:
>>> 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Yann Ylavic <ylavic.dev@gmail.com>
>>>> Gesendet: Mittwoch, 10. April 2019 12:49
>>>> 
>>>> Do user-agents support "Transfer-Encoding: gzip, chunked" currently?
>>>> That'd be the best/easier solution I think.
>>> 
>>> But TE is only hop-by-hop isn't it?. This would mean no e2e
>> compression?
>> 
>> A proxy can still forward hop-by-hop things, e.g. mod_proxy forwards
>> "chunked" encoding if no previous handler/input-filter reads the body.
> 
> My understanding was that mod_proxy "dechunks" the body and "chunks" it again.
> It does not pass it transparently.
> This would be a resource intensive job with compression.

I believe that a proxy could de-chunk without removing the gzip. 
But how would our output filter infrastructure treat that? mod_deflate
stays inactive when faced with an existing Content-Encoding, but does not
watch out for Transfer-Encodings already applied. No resource type output
filter does, right?

Interesting topic.

- Stefan









Mime
View raw message