httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] Move http header parsing into the http_input_filter
Date Tue, 25 Feb 2003 17:46:37 GMT
At 11:04 AM 2/25/2003, Justin Erenkrantz wrote:
>--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.

Yes - error_buckets are neglected right now.  And I agree that we need to
review who's on first when it comes to providing responses to the client.

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

Better how?  Simpler?  Well, if you measure not having to set aside data
that the caller isn't ready to use, it's half of one/half dozen of the other if
the caller does that (trapping those bytes) or pushes it back on the prior
filter.  The point is that whatever API we use should be trivial for module
authors to implement, so I agree simplicity is the key, and we should help
that no matter which flavor is implemented for 2.2.

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

I thought that might be the case :-)

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

My current thinking is use lwp and family to first test the negotiation,
then to create another lwp session with a dirty kluge to pass the
now-upgrading ssl socket into the rsa thunks for upgrading.  It will
be dirty and evil, and I need to spend some time on this.

Once we've proven it works with the kludge, then we can upgrade
the lwp/libwww stuff to support upgrade (and neon and others can
begin to implement for our SVN friends.)

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

Good, we are all on the same page, and this doesn't need to become
the filter wars, redux :-)

FWIW I never see this code going into 2.0.x but only moving forward with
the suggested improvements for the 2.2 release.  I was hoping for a first
release by summer, but that requires a stable API.  Knowing everyone's
busy plates, lets keep our fingers crossed and our dialog flowing so there
might be some hope of that :-)

If 2.2 is filtering and authn/authz both done the 'right way', I'd say that's
enough of a full plate for us to call 2.2 baked and move on further redesign
to 2.4 (file store and expectations for async mpm's all done the right way?)
for release at the end of the year.

Before we can release 2.2 with connection: upgrade tls support, we must
have tests, so I will probably start there.

Bill



Mime
View raw message