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
