Splithttp wrong apln structure [ "h2", "http/1.1" ]

[alireza-2030]

Is alpn equal to [ "h2" ] if it is [ "h2", "http/1.1" ] on the client ?
Because when the server is http/1.1 + tls but the client is h2 and http/1.1, it doesn't connect. But it connects when the client is only http/1.1.

[Fangliding]

When the client has multiple values in apln, it will perform default behavior (if TLS is present, use h2)
If the server alpn only has http/1.1, but client want h2, it may cause handshake failure

[alireza-2030]

When the client has multiple values in apln, it will perform default behavior (if TLS is present, use h2) If the server alpn only has http/1.1, but client want h2, it may cause handshake failure

There are some CDNs that connect sometimes with h2 and sometimes with http/1.1.
The fact that splithttp can't accept http/1.1 and h2 at the same time makes it difficult to connect to these CDNs.

[Fangliding]

When the client has multiple values in apln, it will perform default behavior (if TLS is present, use h2) If the server alpn only has http/1.1, but client want h2, it may cause handshake failure

There are some CDNs that connect sometimes with h2 and sometimes with http/1.1. The fact that splithttp can't accept http/1.1 and h2 at the same time makes it difficult to connect to these CDNs.

After discussion, we have decided not to implement the ALPN negotiation
This CDN behavior is really strange and beyond our scope of consideration. We might not change our decision just because of one CDN
My suggestion is to set two outbounds(one uses http/1.1, one uses h2) and use balancer to select the available one

[alireza-2030]

I know that the alpn list is set by fingerprint, but does what I said have anything to do with fingerprint? What I said is the confirmation of alpn by the client.

As far as I understand, the reason for this error is that fingerprint sends a list of alpn including http/1.1 and h2, but when the server selects http/1.1, the client doesn't accept it. Isn't this an unreasonable limitation?!

@Fangliding

[Fangliding]

I know that the alpn list is set by fingerprint, but does what I said have anything to do with fingerprint? What I said is the confirmation of alpn by the client.

As far as I understand, the reason for this error is that fingerprint sends a list of alpn including http/1.1 and h2, but when the server selects http/1.1, the client doesn't accept it. Isn't this an unreasonable limitation?!

@Fangliding

The function of fingerprints is disguising, but it does not mean that they have all the functions of disguising targets

[mmmray]

but when the server selects http/1.1, the client doesn't accept it. Isn't this an unreasonable limitation?!

we are running into limitations of the golang ecosystem (or rather, utls) where we are unable to read the server's NextProtocol response and have it be respected in golang's HTTP stack. The fix was considered too complicated because setting alpn=http/1.1 for those cases seems practical enough (for now)

The actual fix is to get refraction-networking/utls#74 into utls, which as you can see is a monstrous amount of work.

We can keep it open as a "known issue" but at the same time we may never work on it (as fangliding said we consider those to be edgecases that are not worth the complexity.