I completely agree with OtherBill's assessment here. It would be great if we
could somehow indicate to the handler each of the three situations.
There is no way that I want to marshal 100M of data from a database into the
output stack just to indicate "here is the content-length. etag is XYZ" for
a HEAD request. That could be called "extreme bogosity." :-)
Hmm. Note that cases (2) and (3) are pretty similar. It is just varying
degrees of "how much energy do you want to expend to get the C-L correct?"
It *is* valid to not compute C-L in some cases.
Cheers,
-g
On Wed, Feb 28, 2001 at 10:48:02AM -0600, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 28, 2001 10:35 AM
> Subject: Re: How is this handled?
> >
> > You have just tied every single handler to HTTP. They don't need to
> > return at all. Take a look at the http_header_filter. It will drop any
> > data and never send it. It then sends a return code that says, "Okay,
> > your done now", and the handler ends. This means that we may generate a
> > little bit of data, but we shouldn't have to generate all of it. I can
> > understand a flag that says "should I really generate content or not?",
> > but the handler still shouldn't return, it should send an EOS down the
> > filter stack.
>
> First off, we need to distinguish three cases...
>
> 1. It's a really simple little handler that pushes a bucket + EOS and
> returns. Why test? Let's assume we are break-even and we will simply
> handle the request. The top level protocol dumps the data. Honky dorey.
>
> 2. It's a request for a really big, heavy duty scripted thingy, or perhaps
> mod_autoindex. Yuck, too much CPU, set up the headers and get out quick.
>
> 3. Same request as 2, but the top-level protocol filter tells us we must tell
> him our content-length. Now we need to process the request, in full, so
> the protocol can tell the client how big we were at that moment. Lots of
> CPU, but no alternative. Of course we don't set the content length ourself,
> we let the filter or protocol layer count the silly chars itself.
>
> HEAD doesn't disappear in other protocols, it means just what it says. The question
> is simply how to escape from the second case above, having been told by the protocol
> that it doesn't want our data. If it needs our length we may be in a pickle anyways,
> but at least let's escape when we can.
--
Greg Stein, http://www.lyra.org/
