[PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Brian Pane <br...@apache.org>]

Blaise Tarr wrote:

>With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>streamed to the client but sent in one big chunk.  It appears that the
>C-L filter now buffers the data in every case.  For certain
>applications this is a very undesirable feature, and it would be very
>helpful if the C-L filter could be bypassed (and simply not send back
>a C-L header).  In 2.0.32 streaming behaved beautifully.  Then in
>2.0.36 and 2.0.39 the C-L filter started buffering large chunks.  Now
>in 2.0.40 everything is buffered and a C-L header is always inserted.
>Could the 2.0.32 streaming/C-L behavior be brought back, perhaps
>enabled by a config option?
>
>Blaise
>  
>

Here's a patch that removes the buffering.  Let me know if
it solves the proxy streaming problem.

This patch takes a simplified approach to the C-L computation.
The first time the C-L filter is called for a request, it checks
whether it's been passed an entire response (as denoted by an
EOS at end of the brigade).  If so, it sets the content-length
for the response header.  If not, it just passes all the data
on to the next filter.

With this patch, we'll end up not sending a C-L header on most
shtml or CGI pages.  As a result, the server will add a
"Connection: close" for HTTP/1.0 clients and will use chunked
encoding for HTTP/1.1 clients.

Brian

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Joshua Slive <jo...@slive.ca>]

Justin Erenkrantz wrote:
> On Sun, Aug 18, 2002 at 03:03:40PM -0700, Brian Pane wrote:
> 
>>With this patch, we'll end up not sending a C-L header on most
>>shtml or CGI pages.  As a result, the server will add a
>>"Connection: close" for HTTP/1.0 clients and will use chunked
>>encoding for HTTP/1.1 clients.
> 
> 
> Here's the thing - I think I brought this up before and people
> yelled and screamed that we should always send C-L.  (I'm fairly
> sure I've submitted similar patches to what you sent.)
> 
> I know the RFC allows for Connection: Close or chunking, but people
> seem to not want to use those more than we have to.

It seems to me that people keep saying "somebody said we always need to 
send C-L".  I can't recall ever actually seeing someone say that.  And I 
certainly don't think it is correct.  C-L should be used whenever it is 
available, but not at the expense of buffering the whole request.  If 
anyone disagrees with that, let them explain why.  Otherwise, let's get 
apache sending the content down the wire again.

Joshua.

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Justin Erenkrantz <je...@apache.org>]

On Sun, Aug 18, 2002 at 03:03:40PM -0700, Brian Pane wrote:
> With this patch, we'll end up not sending a C-L header on most
> shtml or CGI pages.  As a result, the server will add a
> "Connection: close" for HTTP/1.0 clients and will use chunked
> encoding for HTTP/1.1 clients.

Here's the thing - I think I brought this up before and people
yelled and screamed that we should always send C-L.  (I'm fairly
sure I've submitted similar patches to what you sent.)

I know the RFC allows for Connection: Close or chunking, but people
seem to not want to use those more than we have to.

So, I wouldn't commit this until you got some buy-in (3
+1s).  And, here's my +1.  =)  -- justin

P.S. I thought we were going to move r->bytes_sent from C-L down
into the core output filter?

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Brian Pane <br...@apache.org>]

rbb@apache.org wrote:

>>To solve the problem that Blaise noted, I believe we'll have to
>>make the content_length filter stop reading buckets altogether
>>(which I think is absolutely the right thing to do, but we'll
>>have to find some other place to compute r->bytes_sent).
>>    
>>
>
>Compute r->bytes_sent in core_output_filter.  That is the only way to get
>an accurate number anyway.
>

I agree.  We'll have to record the size of the response header in
the HTTP filter in order to subtract it later (because mod_log_config
reports bytes sent excluding the header), but that part is easy.

And that will let us avoid doing reads in the C-L filter altogether,
which makes it easier to later add zero-copy output of pipe buckets
on systems where sendfile can handle pipes as input.

I'll post an updated C-L filter patch later today.

Brian

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[rb...@apache.org]

> To solve the problem that Blaise noted, I believe we'll have to
> make the content_length filter stop reading buckets altogether
> (which I think is absolutely the right thing to do, but we'll
> have to find some other place to compute r->bytes_sent).

Compute r->bytes_sent in core_output_filter.  That is the only way to get
an accurate number anyway.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Brian Pane <br...@apache.org>]

Bill Stoddard wrote:

>>Brian Pane writes:
>> > Blaise Tarr wrote:
>> >
>> > >With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>> > >streamed to the client but sent in one big chunk.
>> >
>> > Here's a patch that removes the buffering.  Let me know if
>> > it solves the proxy streaming problem.
>>
>>Thanks Brian.  It's much better now, but it still buffers in 8K chunks
>>as opposed to the 2.0.32 behavior where there was no apparent
>>buffering.
>>
>>thanks,
>>
>>Blaise
>>
>>    
>>
>
>I notice that the code I put in to do non-blocking reads on CGI pipes has
>been removed (or moved from where it lived in the c-l filter).
>

The nonblocking read code is still there, at least in the cvs head.
My patch removes this, though, and instead flushes the data prior
to the pipe bucket and then does a blocking read.

To solve the problem that Blaise noted, I believe we'll have to
make the content_length filter stop reading buckets altogether
(which I think is absolutely the right thing to do, but we'll
have to find some other place to compute r->bytes_sent).

Brian

RE: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Bill Stoddard <bi...@wstoddard.com>]

> Brian Pane writes:
>  > Blaise Tarr wrote:
>  >
>  > >With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>  > >streamed to the client but sent in one big chunk.
>  >
>  > Here's a patch that removes the buffering.  Let me know if
>  > it solves the proxy streaming problem.
>
> Thanks Brian.  It's much better now, but it still buffers in 8K chunks
> as opposed to the 2.0.32 behavior where there was no apparent
> buffering.
>
> thanks,
>
> Blaise
>

I notice that the code I put in to do non-blocking reads on CGI pipes has
been removed (or moved from where it lived in the c-l filter). We need
equivalent function wherever we read from CGI pipes. That probably accounts
for the difference in behaviour. The first read from the server to fetch
bytes from a CGI pipe should be non-blocking. If we do a non-blocking read
and get EWOULDBLOCK, we should flush whatever we've read so far to the
network then do a blocking read on the pipe.  If we have lost this
capability, then our CGI support is broken.

Bill

RE: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Cliff Woolley <jw...@virginia.edu>]

On Mon, 19 Aug 2002, Bill Stoddard wrote:

> Which is the mistake. Someone removed the code I put in (probably because
> that did not understand what it was for?) to do non blocking reads on the
> CGI pipe.

Brian removed it as part of the patch being tested.  The block/nonblock
code is still there in HEAD.

--Cliff

RE: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Bill Stoddard <bi...@wstoddard.com>]

> On Mon, 19 Aug 2002, Blaise Tarr wrote:
>
> > Thanks Brian.  It's much better now, but it still buffers in 8K chunks
> > as opposed to the 2.0.32 behavior where there was no apparent
> > buffering.
>
> This is probably because it's doing a blocking read on the pipe bucket.

Which is the mistake. Someone removed the code I put in (probably because
that did not understand what it was for?) to do non blocking reads on the
CGI pipe.  The code in Apache 2.0.32 was in one aspect better than what was
in 1.3.  If we ever received bytes on the CGI pipe in 2.0, we would set the
reads back to non-blocking again (which would cause another network flush if
a read returned EWOULDBLOCK).

Bill

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Cliff Woolley <jw...@virginia.edu>]

On Mon, 19 Aug 2002, Blaise Tarr wrote:

> Thanks Brian.  It's much better now, but it still buffers in 8K chunks
> as opposed to the 2.0.32 behavior where there was no apparent
> buffering.

This is probably because it's doing a blocking read on the pipe bucket.
It would have to do a nonblocking read to get you what you want.  What
happens if you change APR_BUCKET_BUFF_SIZE (in apr_buckets.h) to like 1kb
or something else?  Does that change the buffering characteristics you're
seeing?  It should, I think.

--Cliff

PS: You might also have to change AP_MIN_BYTES_TO_WRITE, but I'm not sure.

Re: [PATCH] Re: proxy & cgi no longer streamed, C-L filter buffers

[Blaise Tarr <bl...@cnet.com>]

Brian Pane writes:
 > Blaise Tarr wrote:
 > 
 > >With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
 > >streamed to the client but sent in one big chunk.
 >
 > Here's a patch that removes the buffering.  Let me know if
 > it solves the proxy streaming problem.

Thanks Brian.  It's much better now, but it still buffers in 8K chunks
as opposed to the 2.0.32 behavior where there was no apparent
buffering.

thanks,

Blaise