You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2016/02/08 18:07:13 UTC

mod_proxy_http2

FYI: I just checked in a very experimental mod_proxy_http2 that registers on h2:// and h2c:// proxy URLs. I did this naming to have the module totally separate from mod_proxy_http, not wanting to make a mess. So a sample configuration looks like:

    <IfModule proxy_http2_module>
        <Proxy "balancer://h2-local">
            BalancerMember "h2://test.example.org:12346"
        </Proxy>
        ProxyPass "/h2proxy" "balancer://h2-local"
        ProxyPassReverse "/h2proxy" "balancer://h2-local"
    </IfModule>

For this to work I added a connection note "proxy-request-alpn-protos" that is used by mod_ssl to set the ALPN protocols on the SSL instance.

The module so far re-uses connections from earlier requests, but does not do parallel requests on one connection. So, there is no real benefit in using that right now. The idea is to get it working nicely with frontend connections done via HTTP/2 so that multiple HTTP/2 streams on the same frontend connection use a single proxy connection. That would be one step into usefulness.

For the time being, I do not foresee this it be back ported to 2.4.x until more work is done here.

One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.

Cheers,

  Stefan

PS. I did not update Windows Makefiles. I feel bad.

Re: mod_proxy_http2

Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks, Rainer!

> Am 12.02.2016 um 18:28 schrieb Rainer Jung <ra...@kippdata.de>:
> 
> I have renamed modules/http2/config.m4 to modules/http2/config2.m4 (note the "2" in front of the ".m4" suffix). AFAIK this will result in modules/http2 being handled after the module dirs which contain a normal config.m4. Thus the http2 modules get added after mod_proxy to the DSO_MODULES list and the generated httpd.conf will contain their LoadModule behind the ones for mod_proxy.
> 
> I have also added mod_proxy as a prerequisite in the m4 macro for mod_proxy_http2.
> 
> I hope it works as designed ...
> 
> Regards,
> 
> Rainer
> 
> Am 10.02.2016 um 16:41 schrieb Rainer Jung:
>> At this point just a reminder, I might look for it myself:
>> 
>> the config generated for me tries LoadModule for mod_proxy_http2 before
>> mod_proxy and fails, because it can't find the symbol mod_proxy. I guess
>> we need to ensure, that the LoadModule lines we generate for httpd.conf
>> put mod_proxy_http2 after the one for mod_proxy. The current other proxy
>> modules are already behind mod_proxy.

Re: mod_proxy_http2

Posted by Rainer Jung <ra...@kippdata.de>.
I have renamed modules/http2/config.m4 to modules/http2/config2.m4 (note 
the "2" in front of the ".m4" suffix). AFAIK this will result in 
modules/http2 being handled after the module dirs which contain a normal 
config.m4. Thus the http2 modules get added after mod_proxy to the 
DSO_MODULES list and the generated httpd.conf will contain their 
LoadModule behind the ones for mod_proxy.

I have also added mod_proxy as a prerequisite in the m4 macro for 
mod_proxy_http2.

I hope it works as designed ...

Regards,

Rainer

Am 10.02.2016 um 16:41 schrieb Rainer Jung:
> At this point just a reminder, I might look for it myself:
>
> the config generated for me tries LoadModule for mod_proxy_http2 before
> mod_proxy and fails, because it can't find the symbol mod_proxy. I guess
> we need to ensure, that the LoadModule lines we generate for httpd.conf
> put mod_proxy_http2 after the one for mod_proxy. The current other proxy
> modules are already behind mod_proxy.

Re: mod_proxy_http2

Posted by Rainer Jung <ra...@kippdata.de>.
At this point just a reminder, I might look for it myself:

the config generated for me tries LoadModule for mod_proxy_http2 before 
mod_proxy and fails, because it can't find the symbol mod_proxy. I guess 
we need to ensure, that the LoadModule lines we generate for httpd.conf 
put mod_proxy_http2 after the one for mod_proxy. The current other proxy 
modules are already behind mod_proxy.

Regards,

Rainer

Re: mod_proxy_http2

Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 09.02.2016 um 00:38 schrieb Gregg Smith <gl...@gknw.net>:
> 
>> On 2/8/2016 9:07 AM, Stefan Eissing wrote:
>> PS. I did not update Windows Makefiles. I feel bad.
> 
> Don't, I need to play catch-up anyway :)
> 
> Should this be in modules/proxy like all the rest of the mod_proxy_* modules?
> I personally do not care, I was just thinking (which in itself can be dangerous).

There is a tight coupling to mod_http2 and both rely on nghttp2 lib. Since the exact interfaces between both mods are evolving that place fits best. 

Thanks for taking care of the Makefiles!

Stefan

Re: mod_proxy_http2

Posted by Gregg Smith <gl...@gknw.net>.
On 2/8/2016 9:07 AM, Stefan Eissing wrote:
> PS. I did not update Windows Makefiles. I feel bad.

Don't, I need to play catch-up anyway :)

Should this be in modules/proxy like all the rest of the mod_proxy_* 
modules?
I personally do not care, I was just thinking (which in itself can be 
dangerous).

Re: mod_proxy_http2

Posted by Stefan Eissing <st...@greenbytes.de>.
I had the effect that when a socket was determined to be dead, the SNI was cleared and a new connection was made without any SNI. So, I save the first ssl_hostname I see and set that on every new connection.

> Am 09.02.2016 um 15:42 schrieb Yann Ylavic <yl...@gmail.com>:
> 
> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 
>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.
> 
> This is intended (for http/1 at least), why is it an issue?
> When mod_proxy closes the backend connection, it indeed clears any
> associated SNI.
> But it sets the SNI for any new connection, based on the Host
> requested on that connection.
> Keep in mind that with "ProxyPreserveHost on" the requested Host may
> be the one given by the client, which may hence differ for each
> request (mod_proxy won't reuse a connection with a different SNI than
> the Host it requests).

Re: mod_proxy_http2

Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks Yann. My test cases still work, so all is fine.

> Am 11.02.2016 um 14:55 schrieb Yann Ylavic <yl...@gmail.com>:
> 
> On Tue, Feb 9, 2016 at 3:42 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
>> <st...@greenbytes.de> wrote:
>>> 
>>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.
>> 
>> This is intended (for http/1 at least), why is it an issue?
>> When mod_proxy closes the backend connection, it indeed clears any
>> associated SNI.
> 
> OK, I see now, hopefully fixed in r1729826 (backport to 2.4.x candidate...).
> I also removed mod_proxy_http2 workaround code in r1729830, please let
> me know if it still does not work.
> 
> Regards,
> Yann.

Re: mod_proxy_http2

Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Feb 9, 2016 at 3:42 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.
>
> This is intended (for http/1 at least), why is it an issue?
> When mod_proxy closes the backend connection, it indeed clears any
> associated SNI.

OK, I see now, hopefully fixed in r1729826 (backport to 2.4.x candidate...).
I also removed mod_proxy_http2 workaround code in r1729830, please let
me know if it still does not work.

Regards,
Yann.

Re: mod_proxy_http2

Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.

This is intended (for http/1 at least), why is it an issue?
When mod_proxy closes the backend connection, it indeed clears any
associated SNI.
But it sets the SNI for any new connection, based on the Host
requested on that connection.
Keep in mind that with "ProxyPreserveHost on" the requested Host may
be the one given by the client, which may hence differ for each
request (mod_proxy won't reuse a connection with a different SNI than
the Host it requests).

Re: mod_proxy_http2

Posted by Stefan Eissing <st...@greenbytes.de>.
For the request itself, yes. mod_proxy_http2 follows the same pattern as mod_proxy_http. It does not setup a faked request_rec that mod_proxy_http does since I did not need it and did not see the point. Might have missed something.

> Am 09.02.2016 um 15:51 schrieb Yann Ylavic <yl...@gmail.com>:
> 
> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> FYI: I just checked in a very experimental mod_proxy_http2 that registers on h2:// and h2c:// proxy URLs. I did this naming to have the module totally separate from mod_proxy_http, not wanting to make a mess.
> 
> Does mod_proxy_http2 (like mod_http2) still generates an HTTP/1
> request run through the "usual" hooks?
> Can a module/hook/filter (eg. rewrite, headers, security, ...) still
> see/modify/refuse the inner HTTP/1?

Re: mod_proxy_http2

Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
<st...@greenbytes.de> wrote:
> FYI: I just checked in a very experimental mod_proxy_http2 that registers on h2:// and h2c:// proxy URLs. I did this naming to have the module totally separate from mod_proxy_http, not wanting to make a mess.

Does mod_proxy_http2 (like mod_http2) still generates an HTTP/1
request run through the "usual" hooks?
Can a module/hook/filter (eg. rewrite, headers, security, ...) still
see/modify/refuse the inner HTTP/1?

Re: mod_proxy_http2

Posted by Jim Jagielski <ji...@jaguNET.com>.
very very cool!

> On Feb 8, 2016, at 12:07 PM, Stefan Eissing <st...@greenbytes.de> wrote:
> 
> FYI: I just checked in a very experimental mod_proxy_http2 that registers on h2:// and h2c:// proxy URLs. I did this naming to have the module totally separate from mod_proxy_http, not wanting to make a mess. So a sample configuration looks like:
> 
>    <IfModule proxy_http2_module>
>        <Proxy "balancer://h2-local">
>            BalancerMember "h2://test.example.org:12346"
>        </Proxy>
>        ProxyPass "/h2proxy" "balancer://h2-local"
>        ProxyPassReverse "/h2proxy" "balancer://h2-local"
>    </IfModule>
> 
> For this to work I added a connection note "proxy-request-alpn-protos" that is used by mod_ssl to set the ALPN protocols on the SSL instance.
> 
> The module so far re-uses connections from earlier requests, but does not do parallel requests on one connection. So, there is no real benefit in using that right now. The idea is to get it working nicely with frontend connections done via HTTP/2 so that multiple HTTP/2 streams on the same frontend connection use a single proxy connection. That would be one step into usefulness.
> 
> For the time being, I do not foresee this it be back ported to 2.4.x until more work is done here.
> 
> One thing: the ssl_hostname that is used for SNI by the generic proxy utils seems to get lost when the socket needs to reset and is then not available on the next connect. That should affect mod_proxy_http as far as I can tell. Maybe someone with more experience in that module wants to take a look.
> 
> Cheers,
> 
>  Stefan
> 
> PS. I did not update Windows Makefiles. I feel bad.