httpd-dev mailing list archives

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

We're agreeing here.  =)

If there *is* a body right now, that's how it should be.  The
only difference is that we'll return EOS when we believe there
is no body.

> 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.)

That's possible as well.  So, if there is a C-L or T-E, we process
the body (regardless of method), but if there isn't a specified
C-L or T-E, we assume there is no body.  That might work out
better, in fact.  -- justin

Mime
View raw message