httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: buckets and connections (long post)
Date Thu, 22 Oct 2015 16:12:23 GMT
On 22 Oct 2015, at 5:43 PM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:

>> The blocking read breaks the spirit of the event MPM.
>> 
>> In theory, as long as you enter the write completion state and then not leave until
your connection is done, this problem will go away.
>> 
>> If you want to read instead of write, make sure the CONN_SENSE_WANT_READ option is
set on the connection.
> 
> This does not parse. I do not understand what you are talking about. 
> 
> When all streams have been passed into the output filters, the mod_http2 session does
a 
> 
>    status = ap_get_brigade(io->connection->input_filters,...)  (h2_conn_io.c, line
160)
> 
> similar to what ap_read_request() -> ap_rgetline_core() does. (protocol.c, line 236)
> 
> What should mod_http2 do different here?

What ap_read_request does is:

- a) read the request (parse)
- b) handle the request (make decisions on what to do, internally redirect, rewrite, etc etc)
- c) exit, and let the MPM complete the request in the write_completion phase.

What you want to do is move the request completion into a filter, like mod_cache does. You
start by setting up your request, you parse headers, you do the HTTP2 equivalent of ap_read_request(),
then you do the actual work inside a filter. Look at the CACHE_OUT and CACHE_SAVE filters
as examples.

To be more specific, in the handler that detects HTTP/2 you add a filter that processes the
data, then write an EOS bucket to kick off the process and leave. The filter takes over.

The reason for this is you want to escape the handler phase as soon as possible, and leave
the MPM to do it’s work.

Regards,
Graham
—




Mime
View raw message