httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PATCH] Take 2 of the http filter rewrite
Date Mon, 24 Sep 2001 04:27:58 GMT
On Sunday 23 September 2001 09:21 pm, Greg Stein wrote:

> > I don't see how this works at all for pipelined requests.  You moved the
> > HTTP_IN filter from a connection filter to a request filter. But, the
> > only connection filter we have is the CORE_iN filter.  All that filter
> > does, is to pass the socket up to the HTTP_IN filter. The problem is that
> > HTTP_IN will be destroyed in between requests, so the second request will
> > be lost.  I am continuing to read the code, so I may see what I am
> > missing, but in the mean time, Justin, if you could explain that to me,
> > it would make my review go a lot faster.
> There is a create_request hook which inserts the HTTP_IN filter when the
> request is created.
> This seems like a good idea: each instantiation of the HTTP_IN filter is
> for *one* request and one request only. We can be much more sure that state
> is not spanning requests.

No, this is a bad idea, and I still don't see how it works for pipelined requests.
The problem is that it is impossible to make sure that you only read a specific
amount from the socket.  So, the first request is likely to read too much from the
socket, and then it is lost, and the second request will fail to work.  This is why
the HTTP_IN filter needs to be a connection filter.  It is the place where we figure
out when we have hit the end of one request, and are ready for the next.

> Even better, this enables things like the Upgrade: header (RFC 2616,
> S14.42). One request specifies an upgrade, and the next request should be
> handled by a different protocol.

That is possible with the current code.

> * CORE_IN is returning a new socket bucket each time. That socket bucket
>   goes into a brigade associated with the request, so it gets destroyed
> with the request. Not really a problem since the actual socket is cleared
> by a pool, not by the bucket. When the next request asks for more data, it
> will get a new socket bucket. I don't think this is The Right Thing, but
> until we pass an "amount requested" parameter through the input filter
> chain, this will work quite fine.

I don't mind this too much, because of the free list that Cliff is implementing.

> I need to review the code some more. As Justin pointed out, the massive
> change to http_protocol.c makes that hard to review. Other notes may be
> coming soon...

I'm still reviewing too.


Ryan Bloom
Covalent Technologies

View raw message