httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] Move http header parsing into the http_input_filter
Date Tue, 25 Feb 2003 17:04:58 GMT
--On Tuesday, February 25, 2003 10:20 AM -0600 "William A. Rowe, Jr." 
<wrowe@rowe-clan.net> wrote:

> What do you mean?  Returning a non-apr_status_t result?  We just
> got finished hashing that out - since filters are APR brigade based,
> then they must return a recognizable apr_status_t value.  If you
> want to extend that error space in the application error range, you
> can do that for our filters.  But you can't just return 500.

Creating an error bucket that describes the HTTP failure and pushing 
it out to the output_filters.  Then a suitable error code can be 
returned.  But, I was focusing on returning an error to the client 
rather than returning an error to the caller.

> The real answer is pushing back on the lower level filter so the
> next caller (not the same module) reads beginning with the correct
> bytes.

This has been a point of disagreement between us for a long time.  I 
believe we can create a filter model that doesn't rely on pushback. 
I think in the end, the model is better for not having pushback.

> Maybe the comprimize is that only connection level filters should
> support pushback (at least initially) so that things like ssl
> filtering can be inserted and removed painlessly, and the first
> HTTP_IN filter can also be added or dropped for another protocol.

Perhaps.

> I've never advocated the current filter setaside approach, it
> buries bytes  in the wrong filters, if that's what you trying to
> associate me with, Justin.

I mixed up setaside and pushback.  =)  Sorry.

> We support upgrade now in httpd-2.1 .0-dev, so if we break it,
> it would be obvious.  Would be, had we something to test it with
> in perl-framework.

Ah, okay.  Perhaps we should create a test.

> I'll just close by agreeing with FirstBill's noble goals here - and
> point out again that this is the time to revisit what we 'got
> wrong' the first time around with our filter approach :-)  Bring on

Right, I'm all for removing as many instructions as we can and 
cleaning up what we can in the API.  -- justin

Mime
View raw message