apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: What's need for http/2.0?
Date Wed, 24 Sep 2014 23:12:21 GMT
On 23 Sep 2014, at 9:45 PM, Jim Jagielski <jim@jaguNET.com> wrote:

> APR:
> Considering that before we know it, http/2.0 will
> be here, and ignoring httpd for the time being,
> what features/additions do we see as being needed
> to support http/2.0 from an APR library level? How do
> we compare w/ libuv, for example? How "event-aware"
> should APR be, ala libevent?
> 
> HTTPD:
> From the httpd point of view, what does serf
> provide for us to help us get to http/2.0? Should
> we make it a requirement? Are there things we
> need that, instead of making them part of httpd,
> should really be in APR instead? What other external
> libs should we be leveraging?

What I’ve been doing is attempting to solve the various issues around the filter stack and
async support, the idea being that if the filter stack (and common modules like mod_ssl) can
do async, then http/2.0 can follow easily.

From analysing the code it seems the attempt to do async support started last time at the
first handler, when really it needs to start at the last filter (the network filter) and work
backwards.

I intend to commit the async connection filter stack patch posted earlier in the next few
days based on the work so far.

Thinking ahead to the request filter stack (the next bit going backwards, as opposed to the
connection filter stack), the problem we have is the connection filter stack gets called with
empty brigades and has the opportunity to clear data, but the request filter stack does not.
What I had in mind was a special connection filter at the bottom of the stack whose job it
is to “wake up” request filters that it is aware of when the connection filters are woken
up. The trick is to keep track of the requests in flight, and removing them when EOR comes
past. I think it is quite possible to make out filter stack 100% async pretty easily once
this is done.

My shopping list from the MPMS:

- I want to be able to block for read / block for write on connections created by the MPM
(can do)
- I want to be able to control the direction of read/write so when SSL reverses the sense
it can do so (can do)
- I want to be able to mask a connection - ie put events to sleep for a period of time (can’t
do, want it for rate control).
- I want to be able to add connections of my own (ie for mod_proxy, maybe we can do this?)

Regards,
Graham
—


Mime
View raw message