C2 General

> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing <stefan.eiss...@greenbytes.de>
> Gesendet: Mittwoch, 10. April 2019 14:40
> An: dev@httpd.apache.org
> Betreff: Re: keep-alive and vary in 304 responses
> 
> 
> 
> > Am 10.04.2019 um 14:07 schrieb Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com>:
> >
> >
> >
> >
> > C2 General
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Yann Ylavic <ylavic....@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.pl...@vodafone.com> wrote:
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Yann Ylavic <ylavic....@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.

Not sure about this. I guess with TE each hop could be different in what it 
accepts
and generates. This is different from CE. As far as I understand the 
accept-encoding header
is only for CE not for TE.

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

Right.

Regards

Rüdiger

Reply via email to