httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Question about input filters and request bodies
Date Thu, 09 May 2002 22:37:47 GMT
On Thu, May 09, 2002 at 03:16:48PM -0700, Justin Erenkrantz wrote:
> 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.

That sounds reasonable enough to me. From the perspective of a module
author, will I be able to assume that an EOS will occur at the end of
a brigade? It would be nice to simply loop over the incoming buckets
(fetching more brigades as necessary) and procsesing until I reach an EOS.
Please stop me if this is not the pattern you're envisioning.

> The rules I can come up with the top of my head are (need to be
> double-checked):
> - 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
>   this.
> - 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

Looks correct to me. I think if there is a body, unless the RFC explicitly
forbids us from accepting a body with a particular method, then we should
pass it down the filter stack. I don't at all see how multipart/byterange
would work with this (but then again I still think that we aren't using
sentinel buckets liberally enough in our filter implementations.)

-aaron

Mime
View raw message