httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: svn commit: r1890693 - in /httpd/httpd/trunk: changes-entries/ssl_alpn_outgoing.txt modules/ssl/ssl_engine_io.c
Date Fri, 11 Jun 2021 11:05:58 GMT

> Am 11.06.2021 um 12:58 schrieb Yann Ylavic <>:
> On Fri, Jun 11, 2021 at 12:46 PM <> wrote:
>> Author: icing
>> Date: Fri Jun 11 10:45:25 2021
>> New Revision: 1890693
>> URL:
>> Log:
>>  *) mod_ssl: tighten the handling of ALPN for outgoing (proxy)
>>     connections. If ALPN protocols are provided and sent to the
>>     remote server, the received protocol selected is inspected
>>     and checked for a match. Without match, the peer handshake
>>     fails.
>>     An exception is the proposal of "http/1.1" where it is
>>     accepted if the remote server did not answer ALPN with
>>     a selected protocol. This accomodates for hosts that do
>>     not observe/support ALPN and speak http/1.x be default.
> While mod_proxy_http2 sets "proxy-request-alpn-protos", I don't think
> that mod_proxy_http does.
> Should it set "http/1.1" such that if the backend returns something
> other than "http/1.1" or empty we fail the negotiation there too?

I think sending "http/1.1" should be fine, if we are willing to accept an empty response for
this (which we have extra handling for). This will let us continue to work against servers
that do not really handle ALPN.

But servers that do, can react to our "http/1.1" and abort the connection if they cannot fulfill
this. I think that would be good without any likelihood of breaking things (fingers crossed).

In this context: I am thinking of adding SNI hostname and ALPN protocols to the ap_ssl_bind_outgong()
as optional parameterts. I have to check if that would work correctly in all cases, but it
would be much nicer than the current notes.

Cheers, Stefan

View raw message