Re: state of h2 (long)

[Stefan Eissing]

Yeah! I'll get that in tomorrow. Nice work!

> Am 01.03.2016 um 22:13 schrieb Jacob Champion :
> 
>> On Tue, Mar 1, 2016 at 11:08 AM, Jacob Champion  wrote:
>> I still don't have my OpenSSL build process for Windows down enough to
>> test out an h2 proxy, but that'll be my next trick.
> 
> Looks like an HTTP/1.1 -> h2 proxy works for me as well on Windows,
> once I got a functioning SSLProxyEngine. This is cool stuff!
> 
> --Jacob

Re: state of h2 (long)

[Jacob Champion]

On Tue, Mar 1, 2016 at 11:08 AM, Jacob Champion  wrote:
> I still don't have my OpenSSL build process for Windows down enough to
> test out an h2 proxy, but that'll be my next trick.

Looks like an HTTP/1.1 -> h2 proxy works for me as well on Windows,
once I got a functioning SSLProxyEngine. This is cool stuff!

--Jacob

Re: state of h2 (long)

[Jacob Champion]

On Mon, Feb 29, 2016 at 1:55 PM, Jacob Champion  wrote:
> I'm only just figuring out how to actually test the proxy module at
> runtime, though, so... caveat emptor.

FWIW, with that patchset, I was able to get an h2c (plaintext) proxy
working with the nghttp2.org test server. So that's a good sign. I
still don't have my OpenSSL build process for Windows down enough to
test out an h2 proxy, but that'll be my next trick.

That said, the h2c proxy needed an additional patch to work --
mod_proxy_http2's URL canonicalization removes port 80 from h2c://
URLs, but mod_proxy doesn't know which port to use for the h2c
pseudo-scheme, so the proxy fails. One possible solution (patch
attached) is to add the h2c and h2 schemes to the proxy_schemes_t list
in proxy_util.c. I don't know if that's the *right* solution, but it
works for me?

--Jacob


http2-proxy-ports.patch
Description: Binary data

Re: state of h2 (long)

[Jim Jagielski]

> On Mar 1, 2016, at 9:46 AM, Graham Leggett  wrote:
> 
> On 29 Feb 2016, at 10:33 PM, Jim Jagielski  wrote:
> 
>> I've been digging into how we could better leverage serf on the mod_proxy
>> side w/o going the route of mod_serf itself...  Agreed that using
>> pollsets et.al. would be useful. Maybe some of the motorz mpm logic
>> could be used by mod_proxy…?
> 
> I currently think everything we need is now there.
> 
> I am in the process of adding TCP protocol support to the core and to the 
> proxy (in other words we can be a TCP proxy in addition to an HTTP proxy), 
> and am trying to see what problems we run into that stop us doing this 
> asynchronously.

WOW! That is super cool!

Really looking forward to it!

> 
> (What I want to achieve is an SNI proxy, in other words a TCP proxy that 
> interprets enough of an SSL handshake to extract the SNI header, and use that 
> name as the basis of a TCP tunnel to some backend server which then completes 
> that SSL handshake. My end goal is that I can TLS client certificate all the 
> way to a backend server without terminating that TLS connection on the proxy, 
> and not use a dedicated IP per endpoint.)
> 
> Regards,
> Graham
> —
> 

Re: state of h2 (long)

[Graham Leggett]

On 29 Feb 2016, at 10:33 PM, Jim Jagielski  wrote:

> I've been digging into how we could better leverage serf on the mod_proxy
> side w/o going the route of mod_serf itself...  Agreed that using
> pollsets et.al. would be useful. Maybe some of the motorz mpm logic
> could be used by mod_proxy…?

I currently think everything we need is now there.

I am in the process of adding TCP protocol support to the core and to the proxy 
(in other words we can be a TCP proxy in addition to an HTTP proxy), and am 
trying to see what problems we run into that stop us doing this asynchronously.

(What I want to achieve is an SNI proxy, in other words a TCP proxy that 
interprets enough of an SSL handshake to extract the SNI header, and use that 
name as the basis of a TCP tunnel to some backend server which then completes 
that SSL handshake. My end goal is that I can TLS client certificate all the 
way to a backend server without terminating that TLS connection on the proxy, 
and not use a dedicated IP per endpoint.)

Regards,
Graham
—

Re: state of h2 (long)

[Stefan Eissing]

I am very glad that someone is looking into this... if I can be of any help, 
let me know.

> Am 29.02.2016 um 22:55 schrieb Jacob Champion :
> 
> On Mon, Feb 29, 2016 at 9:35 AM, William A Rowe Jr  
> wrote:
>> On Sun, Feb 28, 2016 at 1:37 PM, Gregg Smith  wrote:
>>> 
>>> Hi Stefan,
>>> 
>>> I've had a real lack of time lately to do much on trunk's mod_http2 on the
>>> windows side. The new mod_proxy_http2 requires a few functions from
>>> mod_http2 and with what time I have had I have been unsuccessful figuring
>>> out how to get these functions exported. So if you (or anyone else) can
>>> figure this out, I'd appreciate it
>> 
>> Looking at this today.
> 
> Oops, I probably started duplicating some of your work then. In case
> it is still useful... my current work in progress is a set of three
> patches, up at
> 
>   https://github.com/jchampio/httpd/commits/dev/cmake-http2
> 
> The first two patches are general CMake changes:
> - use CMake generator expressions so that multi-configuration
> generators (e.g. Visual Studio 2015) can correctly install build
> artifacts like PDBs
> - a change to path quoting so that we can install to paths with quotes
> in them (e.g. "Program Files")
> 
> The third patch is the one that gets mod_proxy_http2 compiling (export
> the three h2_iq symbols, fix up the APLOG usage, etc).
> 
> I'm only just figuring out how to actually test the proxy module at
> runtime, though, so... caveat emptor.
> 
>> Between Jeff's first effort @ 
>> https://github.com/trawick/nghttp2-minimal-cmake
>> and a broader effort w/
>> https://github.com/tatsuhiro-t/nghttp2/issues/448#issuecomment-182849066
>> the cmake builds for nghttp2 look almost simple, which is what I'm looking
>> at for the moment.
> 
> Ooh, nice! My MinGW build of nghttp2 this morning was a little
> painful... looking forward to having this.
> 
> --Jacob

Re: state of h2 (long)

[Jacob Champion]

On Mon, Feb 29, 2016 at 9:35 AM, William A Rowe Jr  wrote:
> On Sun, Feb 28, 2016 at 1:37 PM, Gregg Smith  wrote:
>>
>> Hi Stefan,
>>
>> I've had a real lack of time lately to do much on trunk's mod_http2 on the
>> windows side. The new mod_proxy_http2 requires a few functions from
>> mod_http2 and with what time I have had I have been unsuccessful figuring
>> out how to get these functions exported. So if you (or anyone else) can
>> figure this out, I'd appreciate it
>
> Looking at this today.

Oops, I probably started duplicating some of your work then. In case
it is still useful... my current work in progress is a set of three
patches, up at

   https://github.com/jchampio/httpd/commits/dev/cmake-http2

The first two patches are general CMake changes:
- use CMake generator expressions so that multi-configuration
generators (e.g. Visual Studio 2015) can correctly install build
artifacts like PDBs
- a change to path quoting so that we can install to paths with quotes
in them (e.g. "Program Files")

The third patch is the one that gets mod_proxy_http2 compiling (export
the three h2_iq symbols, fix up the APLOG usage, etc).

I'm only just figuring out how to actually test the proxy module at
runtime, though, so... caveat emptor.

> Between Jeff's first effort @ https://github.com/trawick/nghttp2-minimal-cmake
> and a broader effort w/
> https://github.com/tatsuhiro-t/nghttp2/issues/448#issuecomment-182849066
> the cmake builds for nghttp2 look almost simple, which is what I'm looking
> at for the moment.

Ooh, nice! My MinGW build of nghttp2 this morning was a little
painful... looking forward to having this.

--Jacob

Re: state of h2 (long)

[Jim Jagielski]

> On Feb 26, 2016, at 12:06 PM, Stefan Eissing  
> wrote:
> 
>- And: it could be done for mod_proxy_http, too! I see no reason why a 
> single
>  thread cannot use pollsets to juggle a couple of http/1.1 backend 
> connections
>  on top of a http/2 master connection.
> 

I've been digging into how we could better leverage serf on the mod_proxy
side w/o going the route of mod_serf itself...  Agreed that using
pollsets et.al. would be useful. Maybe some of the motorz mpm logic
could be used by mod_proxy...?

Re: state of h2 (long)

[Eric Covener]

On Mon, Feb 29, 2016 at 12:35 PM, William A Rowe Jr  wrote:
> Huge props to everyone who's contributed on cmake for both httpd's build
> and for our components!

+1, very cool.

-- 
Eric Covener
cove...@gmail.com

Re: state of h2 (long)

[William A Rowe Jr]

On Sun, Feb 28, 2016 at 1:37 PM, Gregg Smith  wrote:

> Hi Stefan,
>
> I've had a real lack of time lately to do much on trunk's mod_http2 on the
> windows side. The new mod_proxy_http2 requires a few functions from
> mod_http2 and with what time I have had I have been unsuccessful figuring
> out how to get these functions exported. So if you (or anyone else) can
> figure this out, I'd appreciate it


Looking at this today.

Had some great luck during our hack at HackIllinois using cmake (my student
was having issues with linux on BusyBox and didn't have a whole lot of
extra
toolkit installed under windows, so we trying to run with the minimal extra
packages we could between the trunk repositories to build on Studio 2015).
I documented the efforts here, but so far this ignores openssl/http2...

https://wiki.apache.org/httpd/WindowsTrunkCompilation

Between Jeff's first effort @
https://github.com/trawick/nghttp2-minimal-cmake
and a broader effort w/
https://github.com/tatsuhiro-t/nghttp2/issues/448#issuecomment-182849066
the cmake builds for nghttp2 look almost simple, which is what I'm looking
at
for the moment.

Huge props to everyone who's contributed on cmake for both httpd's build
and for our components!

Cheers,

Bill

Re: state of h2 (long)

[Gregg Smith]

Hi Stefan,

I've had a real lack of time lately to do much on trunk's mod_http2 on 
the windows side. The new mod_proxy_http2 requires a few functions from 
mod_http2 and with what time I have had I have been unsuccessful 
figuring out how to get these functions exported. So if you (or anyone 
else) can figure this out, I'd appreciate it.


Gregg

On 2/26/2016 9:06 AM, Stefan Eissing wrote:

Things winding down here a bit before the weekend (at least I try) and I thought
I'd summarize a bit the state of HTTP/2 in our little project, because...well, 
some
might be interested and certainly no one has the time to follow all my crazy 
submits.

* trunk<->  2.4.x
   the version in 2.4.x has gathered a bit dust, as we made several tweaks in 
trunk
   in regard to async connection handling and scoreboard updates. These have 
all been
   backported, except one. Once that is through, I'll make a backport of 
mod_http2,
   so that 2.4.x gets all the nice new things.

* nice new things
   in trunk we have the following additions:
   - http/2 connections get queued properly when they become idle on the event 
mpm.
 that should be nice for people with many connections or long keepalives 
configured.
   - timeouts and keepalive timeouts are respected as for http/1 connections, 
no extra
 configuration.
   - stability: with the interim releases in github and the help of nice 
people, several
 improvements have been made here and the 1.2.5 github has no reported open 
blockers,
 hanging connections or segfaults. All those changes are in trunk.
   - server push: the module now remembers in each open connection which 
resources
 have already been pushed, using hash digests. This also implements an 
outsketched
 extension https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/ 
whereby
 clients can send a highly compressed digest of the resources they have. 
This is
 very early and experimental and we'll see how/if browsers adapt this and 
how
 it will change over time.
   - To offload worker threads, the module allows a number of file handles to 
have
 open. So, ideally, when serving static content, workers just lookup the 
file,
 return and the master connections streams them out. This number existed 
before
 as number per master connection. Now this number is multiplied by the 
number of
 workers and made a process wide pool where h2 connections can borrow 
amounts.
 Still, I am not totally satisfied with this. This should not be 
configurable, but
 httpd itself should check for ulimits of the process and configure itself, 
I think.
   - the scoreboard shows more information for h2 connections, such as its 
connection
 state and some stream statistics. Maybe the h2 workers should show up in a 
separate
 section on day...
  127.0.0.1 http/1.1test2.example.org:12345 wait, streams: 
1/100/100/0/0 (open/recv/resp/push/rst)
   - request engines! which leads us to:

  * mod_proxy_http2
is configured just like other proxy modules with by using 'h2' or 'h2c' as 
url prefix
in the configuration directives.


BalancerMember "h2://test2.example.org:12346"

 ProxyPass "/h2proxy" "balancer://h2-local"
 ProxyPassReverse "/h2proxy" "balancer://h2-local"
 
 Initially, it used one h2 connection for one request. The connection, and 
the http2
 session associated with it, was reused via the nice proxy infrastructure.

 This is how things still are when the original connection is http/1.1
 When this is http/2 itself, however, the first such request will register a
 "request engine" that will accept more requests while the initial one is 
still
 being served and use the same backend connection for it. When the last 
assigned
 request is done, it unregisters and dissolves into fine mist.
 The connection and h2 session stays as before, so a new request can reuse 
the connection
 in a new engine.

 This works quite (but not 100%) reliable at the moment. There are still 
some races when
 requests are sent out while the backend is already shutting down and the 
retry does
 not catch all cases.

 Important here is that requests for engines process all the usual hooks 
and filters
 and yaddayadda of our infrastructure, just like with http/1.1. This works 
as follows:

 - incoming request is handed to a worker thread as is done for all by 
mod_http2
 - httpd/proxy identifies the handler of mod_proxy_http2 as the responsible
 - mod_proxy_http2 finds out what backend it shall talk to and ask from 
mod_http2
   (if present, the usual optionals) if there is already an engine for this 
backend,
   and that it is willing to host one if there is not.
 - mod_http2, if it has one, *freezes* the task for this request (which 
holds the
   replacements for the core input/output filters on this slave connection) 
and
   returns 

Re: state of h2 (long)

[Luca Toscano]

Hi Stefan!

2016-02-26 18:06 GMT+01:00 Stefan Eissing :

> Things winding down here a bit before the weekend (at least I try) and I
> thought
> I'd summarize a bit the state of HTTP/2 in our little project,
> because...well, some
> might be interested and certainly no one has the time to follow all my
> crazy submits.
>

Thanks a lot for all the info!


>
> * nice new things
> ...
>   - the scoreboard shows more information for h2 connections, such as its
> connection
> state and some stream statistics. Maybe the h2 workers should show up
> in a separate
> section on day...
>  127.0.0.1  http/1.1test2.example.org:12345 wait, streams:
> 1/100/100/0/0 (open/recv/resp/push/rst)
>

Do we already have h2 workers data in the scoreboard (and therefore we just
only need to modify mod_status) or not? I am really interested in working
on mod_status if you need any help!


>   - request engines! which leads us to:
>
>  * mod_proxy_http2
>

This is really interesting, especially because (from what I know) httpd is
the only one supporting proxied http2 requests at the moment. Do you think
that it is too early to start a documentation page in trunk about it?
(Didn't find one but I might be wrong)


> Anyways, let me hear what you think. Anyone wants to help?


Would it be ok to start an how-to section about http2 in trunk using the
following (great) starting points? (Anybody interested please let me know)

https://icing.github.io/mod_h2/internals.html
https://icing.github.io/mod_h2/howto.html

Thanks!!

Luca