httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 20:10:31 GMT wrote:
>                                                               You had two
> filters that were both reading data and saving it to the same place at the
> same time.  

What two filters?  Only http_filter and bgets are involved.  In header
mode, http_filter turns into a no-op, and no content mangling filters
are allowed on the stack, so bgets was essentially reading directly from
core_input_filter, just like in 2.0a5 except that Jeff taught it to
understand bucket brigades.  

In body mode, bgets and getline are out of the picture altogether. 
Content filters are added as/after the headers are parsed so we have
have a clue about which content filters might make sense for this
request.  The content body data is read thru http_filter which now
switches into body mode and starts acting as the http length cop.

There's really not enough difference between the two patches to get
excited about.  You implement "unread" by storing the excess raw data in
http_filter's context.  Cool.  Our patch does exactly the same thing
using c->raw_data so bgets can see it.  We both used c->remaining
exactly the same way.

At the time we came up with this patch, telnet was pretty broken.  This
patch fixed telnet until one of your commits to core_input_filter IIRC
re-broke it.  OK, we cheated and started with working code out of buff
which of course is evil.  Nope, we didn't test it with dechunk_filter,
or other another length changing input filter.  They didn't exist. 
Still don't, last time I checked.

But then I fixed telnet, which was easier because you simplified
http_filter.  It was kinda fun too, except for the sleep deprivation. 
So peace already.  I surrender.  Let's ditch the Jeff & Greg bgets patch
and move on.  

>             The problem as I see it, is that ap_get_client_block knows
> when it hits the end of the body.  Currently, no other code in any patch I
> have seen knows that information.  

Isn't this a universal problem with length changing content filters? 
ap_get_client_block or its callers *can't* detect end-of-body any more. 
It _has_ to be something like http_filter that detects end-of-body.  It
could set c->remaining to zero to signal this, or pass up a special
bucket, or flag, or whatever.  I'm not picky, as long as it works.

>                    the text at the top of your patch says
> that if http_filter reads past the end of the body, then it gets put back
> in c->raw_data.  Well, if I read this, it says to me that http_filter
> reads some data, and it must make it all the way up to
> ap_get_client_block.  

Nope, see above.  When http_filter is in body mode, it is the length
cop.  It might read too much from core_input_filter.  If so, the excess
is unread via c->raw_data _without_ ever going thru any content altering

>   Unfortunately, this is broken, because by the
> time it gets to ap_get_client_block, it has been through multiple filters,
> one of which could have seriously screwed up the data.

OK, now I understand why you were so shook up about the concept.  Sorry
if I'm slow.  (Bass players are _supposed_ to be laid back.  It's in our
union rules :-) But c->raw_data never contained anything but raw data,
exactly like f->ctx in http_filter as of yesterday.  


View raw message