httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Date Thu, 22 Feb 2001 07:58:00 GMT
On Thu, 22 Feb 2001 rbb@covalent.net wrote:

> On Thu, 22 Feb 2001, Bill Stoddard wrote:
>
> > > > > stoddard    01/02/21 13:14:33
> > > > >
> > > > >   Modified:    modules/http http_protocol.c
> > > > >   Log:
> > > > >   BUFF is gone!
> > > >
> > > > BUFF may be gone, but were these issues ever REALLY investigated?
> > > >
> > > > Ryan
> > > >
> >
> > SAFEREAD is an optimiation for handling pipelined requests. When we receive a
> > pipelined request, we want to pipeline the respose back (e.g., combine
> > mulltiple responses in a single buffer until thebuffer is filled before
> > flushing to the network).
> >
> > Here is how SAFEREAD mode worked
> >
> > Issuing a bread() on a BUFF in SAFEREAD mode caused the BUFF code to first
> > issue a select() on the socket to see if there was more bytes available (i.e.,
> > a pipelined request). If more bytes were available, bread() returned those
> > bytes. If no bytes were available, any response hanging around in BUFF was
> > flushed before the blocking read was issued. Fairly straightforward.
> >
> > check_pipeline_flush() in http_request.c is intended to do the same thing, but
> > I've not actually tested it because I don't like the function is implemented.
> > check_pipeline_flush() issues an ap_get_brigade(r->input_filters, bb,
> > AP_MODE_PEEK)  which seems overkill.  This function would be much cleaner if
> > it used an apr_select call on the socket to see if bytes were available to be
> > read.  If no bytes were available, then send the flush down the filter chain.
> > If bytes are available, handle the crlf on the end of POST requests in the
> > input chain rather than in the AP_MODE_PEEK code. In fact, I would suggest
> > getting rid of AP_MODE_PEEK altogether.
>
> Doing a select won't do what you want it to do.  There is a chance that we
> have already read the second request from the socket, and it is sitting in
> a lower filter.  A higher filter can NOT just skip the rest of the filters
> and go straight to the network, it must go through the filter chain.

BTW, the pipeline_flush stuff does work, I have tested it quite a bit
already.  Not that more testing isn't always appreciated.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message