httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: How is this handled?
Date Wed, 28 Feb 2001 16:48:02 GMT
From: <rbb@covalent.net>
To: <new-httpd@apache.org>
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.



Mime
View raw message