httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
Date Mon, 02 Jan 2006 19:52:40 GMT
On Dec 31, 2005, at 9:55 PM, Brian Pane wrote:
> On Dec 31, 2005, at 6:50 PM, Roy T. Fielding wrote:
>
>> The nonblocking yield should happen inside ap_rgetline (or its
>> replacement), not in the calling routine.  The thread has nothing
>> to do until that call is finished or it times out.
>
> On the contrary, the thread has some very important work to do before
> that call finishes or times out: it has other connections to  
> process.  If
> the thread waits until the ap_rgetline completes, a server  
> configuration
> sized for multiple threads per connection will be vulnerable to a  
> trivially
> implementable DoS.

When I say "thread", I mean a single stream of control with execution
stack, not OS process/thread.  An event MPM is going to have a single
stream of control per event, right?  What I am saying is that the
control should block in rgetline and yield (return to the event pool)
inside that function.  That way, the complications due to yielding are
limited to the I/O routines that might block a thread rather than
being spread all over the server code.

Am I missing something?  This is not a new topic -- Dean Gaudet had
quite a few rants on the subject in the archives.

>>  In any case,
>> this code should be independent of the MPM and no MPM is going
>> to do something useful with a partial HTTP request.
>>
>> I say -1 to adding the input buffer variables to the request_rec.
>> Those variables can be local to the input loop.
>
> Are you proposing that the buffers literally become local variables?
> That generally won't work; the input loop isn't necessarily contained
> within a single function call, and the reading of a single request's
> input can cross threads.

I am saying it doesn't belong in the request_rec.  It belongs on the
execution stack that the yield routine has to save in order to return
to this execution path on the next event.  The request does not care
about partial lines.

> It would be feasible to build up the pending request in a structure
> other than the request_rec, so that ap_read_async_request() can
> operate on, say, an ap_partial_request_t instead of a request_rec.
> My preference so far, though, has been to leave the responsibility
> for knowing how to parse request headers encapsulated within
> the request_rec and its associated "methods."

Maybe you should just keep those changes on the async branch for now.
The rest of the server cannot be allowed to degrade just because you
want to introduce a new MPM.  After the async branch is proven to be
significantly faster than prefork, then we can evaluate whether or
not the additional complications are worth it.

....Roy

Mime
View raw message