httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Tue, 17 Oct 2000 15:10:11 GMT


rbb@covalent.net wrote:
> 
> > The _only_ thing that is stopping me from fixing folding is that we
> > don't have a bucket brigade equivalent to ap_blookc() AFAIK.  If a
> > bucket expert will provide such a function, I will be more than happy to
> > fix folding.  I believe the blookc equivalent needs to be non-blocking.

On further thought, blookc shouldn't mess with the blocking
characteristics at all.  1.3 logic: blookc->bgetc->bread->iol_land. 
Think of a character mode telnet client.  We should be able to look
ahead to its next character without changing the way the HTTP layer
works a whole lot, which says blocking to me.
  
> >
> > With that in mind, do you still have a concern with my code?  IMO it is
> > pretty basic stuff.  I got pretty confused trying to figure out what all
> > those variables did while debugging telnet, and I honestly feel what I
> > committed is easier to understand.
> 
> It is easier to understand, 

Thanks!
>              I'm just concerned that a lot of that code was
> there to help with folding, 

No sir.  It was just excessive bookkeeping.

Folding is basically: check for the right conditions, look ahead one
character, and iterate the loop if you like the character.  That's it. 
Piece o' cake, once we get the lookahead.

>  and now its not there.  :-)
> 
> As far as folding goes, the way I was thinking about this was that we
> could finally implement the blocking argument for socket buckets, 

Shouldn't need to change blocking.  Sorry for the premature brain fart.

>      read the
> next header, and store it off to the side if we aren't going to fold.  

That actually will work pretty well.  I was concerned at first that we
might suck up body accidentally, but the loop iteration tests have
enough smarts to know when we're at end-of-headers. 

> The
> only place to save it is the conn_config in the conn_rec.  

Why not core config in the r?  The excess header *has* to be part of
this request, or we broke something.  Actually it could share the stash
that get_client_block uses, as a union perhaps, since we're either in
header mode, body mode, or broke mode.  But I'm not religious about this
kind of thing.  

> If we see /r/n
> as the line, then obviously we stop trying to fold.  :-)
> 

Yup.  This stops us from reading body.  

> Does that make any sense?
> 

Yessir.  Except for the blocking, and that's my fault.

I'll start on this after lunch (usual disclaimer: unless someone else
gets there first), using the core config in the r.  Holler soon if you
have a concern.

Greg

Mime
View raw message