async reads - request for comments Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c

[Brian Pane <br...@apache.org>]

I'll probably have time to work on the changes to ap_core_input_filter 
and/or
the async read code this weekend (starting on the async-read-dev branch).
If anyone has a strong argument for or against putting the buffering of
partial lines inside the ap_core_input_filter context, please speak up.

Thanks,
Brian

On Jan 7, 2006, at 11:57 PM, Brian Pane wrote:

> On Jan 3, 2006, at 8:07 AM, Justin Erenkrantz wrote:
>
>> AFAICT, ap_read_async_request() on the branch can't handle a partial
>> line correctly.
>>
>> Noting of course that ap_core_input_filter is 'cute' and masks EAGAIN.
>>  So, you'll never see EAGAIN from this code path!  As I said earlier,
>> the EAGAIN logic in httpd is completely suspect.
>>
>> Furthermore, as I read it, ap_read_async_request is assuming that it
>> gets a complete line from getline_nonblocking - which almost certainly
>> won't be the case.  -- justin
>
>
> I'm currently working on changing ap_core_input_filter so that it
> doesn't mask the EAGAIN in AP_MODE_GETLINE mode.  There's
> a catch, though:
>
>     if (mode == AP_MODE_GETLINE) {
>         /* we are reading a single LF line, e.g. the HTTP headers */
>         rv = apr_brigade_split_line(b, ctx->b, block, HUGE_STRING_LEN);
>
> if apr_brigade_split_line returns APR_EAGAIN, it will have
> consumed the partial line and put it in b.  So if core_input_filter
> returns rv at this point, the caller will receive the partial line and
> EAGAIN.  We'll need to do one of two things:
>
> - Buffer the partial line in ap_core_input_filter, by removing the
>   buckets from b and putting them back at the start of ctx->b.
>
> - Or buffer the partial line in getline_nonblocking (or  
> read_partial_request).
>
> Anybody have a preference among these options?
>
> Brian
>