httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Question about input filters and request bodies
Date Thu, 09 May 2002 22:16:48 GMT
On Tue, May 07, 2002 at 01:09:06PM -0700, Aaron Bannert wrote:
> I have a module that needs to suck in the request body. I'm trying to
> use ap_get_brigade to do this, as this seems most natural (as opposed
> to the ap_*_client_block() family). The semantic that I'm looking for
> is something simple like this: "retrieve all the buckets that represent
> a request body". I would expect there to be a way to determine if an
> input body was not present, without causing the server to block on the
> socket waiting for input. As it is I see no simple way to do this. The
> only parallel I see is much more complicated (call ap_get_brigade with
> the AP_MODE_READBYTES mode, forcing buckets in to n-sized chunks even
> if that is not an optimal form, stopping when an EOS comes across (?) ).
> Is there a better way to deal with this? Shouldn't the most prevalent mode
> of an input filter be something as simple as AP_MODE_GIVE_ME_A_BUCKET?

No.  I think the best way to handle this situation is to teach
HTTP_IN about what requests may have input bodies.  If the request
doesn't indicate a body, an EOS bucket is returned.

The rules I can come up with the top of my head are (need to be
- GET and HEAD can't have bodies (I think there are others that may
  do this.)  The RFC says that the bodies should be ignored.  So,
  there may need to be some way to discard the bodies.  But, it also
  says that proxies SHOULD forward them.  We may have to think about
- Must have either C-L or a valid T-E.
- Have to support multipart/byteranges (we aren't doing this now!)

So, something like this in ap_http_filter:
if (!ctx) {
    if method is GET or HEAD { return EOS bucket in brigade; }
    if T-E { set body type to be T-E }
    else if C-L { set body length to C-L }
    else { return EOS bucket in brigade; }
    ..normal init..

..normal code...

What do you think of this?  I think this means making BODY_NONE
state invalid.  It was primarily there before because we were
using ap_getline in HTTP_IN - now we use the brigade calls, so this
state is no longer needed.  -- justin

View raw message