Good Morning Lukas,
Thank you!
This was indeed the change which was necessary.
Removed the ssl_fc_sni part in my ACLs, reactivated h2 and I’m back on track.
Cheers (from a happy http2 user),
Chris
> Am 11.12.2017 um 23:48 schrieb Lukas Tribus <lu...@ltri.eu>:
>
> Hell Chris,
>
>
> 2017-12-11 20:04 GMT+01:00 Christian Bönning
> <christian.boenn...@noerdisch.de>:
>> Hi,
>>
>> I recently switched from nginx to haproxy 1.8 for SSL termination and load
>> balancing in front of my application but saw an odd behaviour with "alpn
>> h2,http/1.1" enabled on my frontend.
>>
>> I'm running a single haproxy instance in front of my applications switching
>> between them based on "ssl_fc_sni" or HTTP host.
>> [...]
>> use_backend backend_app_jira if { ssl_fc_sni -i jira.example.com ||
>> hdr(host) -i jira.example.com }
>> use_backend backend_app_confluence if { ssl_fc_sni -i confluence.example.com
>> || hdr(host) -i confluence.example.com }
>
> That's whats wrong. You can't route based on ssl_fc_sni or HTTP Host.
> This will lead to the this exact behavior.
>
> You have to route based on HTTP Host header *only*. The SNI value will
> be "jira.example.com" for the entire H2 (or H1) session, even when you
> request something on confluence - that is if your certificate handles
> both domains. SNI is for certificate selection only, you need to look
> at host header (*only*), for deciding with backend to choose for a
> specific HTTP transaction.
>
>
> The difference between h2 and http/1.1 is that h2 keeps the SSL
> session alive for a longer time (timeout server or timeout client)
> than http/1.1 (timeout http-keep-alive). You browser may also not
> reuse the SSL session for a different domain in http/1.1, while it
> does soin h2. So that's why you may see different behavior in h2,
> depending on your browser.
>
>
>
> Regards,
> Lukas
