httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: C-L or T-E: chunked for proxied request bodies
Date Thu, 30 Dec 2004 21:29:02 GMT
On Thu, 30 Dec 2004 21:12:16 +0100, Jan Kratochvil
<rcpt-dev.AT.httpd.apache.org@jankratochvil.net> wrote:
> Hi,
> 
> On Thu, 30 Dec 2004 19:54:05 +0100, Jeff Trawick wrote:
> > On Thu, 30 Dec 2004 18:47:48 +0100, Jan Kratochvil
> > <rcpt-dev.AT.httpd.apache.org@jankratochvil.net> wrote:
> ...
> > An interesting issue is that what is in 2.0 now is optimal when it
> > works, and it works in a common real-world scenario (client sends C-L
> > and no filters modify the request body size).
> 
> Sorry for chatting without code sample etc.
> 
> * If no active filters are detected after headers parsing pass the
>   single request unchanged through this connection by its C-L despite
>   its possible "keepalive".

that's the goal of the patch I posted earlier this afternoon; I didn't
consider keepalive setting and hope it is irrelevant ;)

> * Use currently 2.1-implemented C-E "chunked" as fallback.

for the very short term, I agree; if my prior patch to try to preserve
some of the optimal handling in 2.0 is acceptable, then we could fall
back to chunked

for the long term, here is my current understanding of a better solution.

1. special case: 
    if client specified C-L and either C-L is zero or there are no
input filters or some magic envvar is set to indicate that filters
don't change the size:
    pass through the C-L header and stream the request body, if any

2. normal:
   read enough request body to see if there is more than 32K of
request body...
   if <= 32K: 
     send the C-L and the small request body;
   else if some magic variable is set to force calculation of C-L:
     get temporary file;
     read entire request body into file;
     send calculated C-L;
     send request body from the file;
  else:
    use chunked encoding and stream the request body

> Will there really remain no active filters in the common case?

strictly speaking, there are always filters; but we're just worried
about filters which can modify the request body; it is common to have
a configuration in which there are no filters which modify the request
body...

> At least ap_byterange_filter() gives up but chunk_filter() never does.
> Is it possible to patch such filters? It would be performance wise. :-)

those two filters aren't used on input, and they aren't used when
forwarding the request to the origin server

Mime
View raw message