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 Thu, 12 Oct 2000 17:41:32 GMT

> How do you know when you have hit the end of the request?  There are only
> three solutions.
> 
> 1)  Implement an all-knowing filter
> 2)  Allow push-back from one filter to another
> 3)  Specify the max amount of data allowed to be read.
> 
> 1 won't be maintainable into the future.
> 

Obviously

> 2 is a scary design, because it allows two filters access to the same
> brigade at the same time.  Sooner or later, we will clobber data that way.
>

ummm, I don't see a problem here.  I'm not scared at all.  If it really
was the "same time" then it would be harder.

Only a single thread can access a bucket brigate or filter chain as
implemented today.  We don't have any problem passing brigades between
filters in the forward direction.  Why would we all of a sudden have
problems passing them backwards?  Assuming of course that we use a
pointer that belongs to the thread, or a callback, or a different
function pointer in the filter structure for the pushback/unget brigade
routine, or...  (plug in your favorite technique here)

What am I missing here?  I didn't get enough sleep last nite, but I did
think about this stuff when I was well rested.

> 3 is what we are implementing.  Basically saying, http_filter understands
> two modes, but not when we are in each mode.  We tell http_filter which
> mode we are in by the arguements we pass to it.  This is just like using
> c->remaining, except it is safer.

I think this is OK for now, but the global argument passing thing is
pretty shaky.  Sure, I love the concept of parameters.  But since we
don't have a clean way today to target a specific filter with a specific
dynamic parameter, the "one length argument applies to all filters"
approach means that we can't implement any input filters that increase
the length of the content.  gunzip, multi-byte charset xlation, ... 
Once one filter increases the length of the data, what should the next
filter upstream do with the length argument?  How would you implement
those input filters in a general fashion?

Greg

Mime
View raw message