tls + proxy_protocol How to set HTTP/2 ALPN?

Hi I’m using tls offloading with proxy_protocol and it’s great (I see the corrent client IP), but I still can’t get a HTTP/2 connection negotiated in any way (including HTTP2 prior knowledge).

It seems that there is no way to set TLS ALPN to be h2, it’s always http/1.1. Is there any way to tell the fly app to advertise HTTP2 support on a specific port.

# This is my networking section
[[services]]
  internal_port = 8080
  protocol = "tcp"

  [[services.ports]]
    handlers = ["tls", "proxy_proto"]
    port = "443"

Server hello examples (note it’s not h2):

image

Nevermind, found it
Here GitHub - fly-apps/grpc-service: Running gRPC services on Fly.io
And here

2 Likes

Nice! What kind of app are you building?

A .NET 6 gRPC app. Wrote my own connection middleware to process proxy protocol header. It seems that fly is only using plain text PROXY V1, so it could been a bit simpler.

Currently having issues with connection processing where Kestrel complaints about h2/h2c and http/https scheme mismatch, since it’s not aware about TLS offload (endpoint is HTTP2 only). And also it’s not possible to process both h2c and http/1.1 on same port.

It seems that Kestrel needs to know the ALPN to choose the correct protocol.
I can force it to be h2, but it will break if client used http/1.1.

Probably can hack it to detect HTTP2 client preface as in RFC7540

If fly.io supported PROXY V2 then it would be possible to use PP2_TYPE_ALPN

1 Like

Will consult with the team and get back to you :smile:

Sounds reasonable.

Nice! For now I managed to make it work with the client preface hack. Now I’m figuring out the how to use OpenTelemetry stuff for metrics (on a isolated endpoint without proxy protocol)

You can find my current middleware here.

Wait a second: Is Fly’s proxy_proto handler v1 only? If so, it shouldn’t support for IPv6 (which I think it does)?

No, IPv6 works correctly with even with proxy V1, see the example here

  - TCP/IPv6 :
      "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n"
    => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = 104 chars
1 Like

^ Thanks.


@jerome et al any timeline for support for proxy_proto v2? The ClientHello contents (specifically, ALPN and SNI) sent in v2 is helpful for our use-case.

Any update on supporting PROXY v2? Our middleware (request router) needs to peek at TLS ClientHello, too.

Update: We have a working branch for proxy proto v2.

I’m going to test it out a bit before letting you in on it.

1 Like