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
