1864877 - firefox is ignoring Alt-Svc header

Status: NEW

(Core :: Networking, defect, P3)

Description

[kirukaa]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Steps to reproduce:

I am using QUIC enabled load-balancer where the load-balancer insert Alt-Svc header in the first HTTP/1.1 response but mozilla is not switching to HTTP/3 for subsequent requests, instead it continues with HTTP/1.1 however randomly it works which means mozilla is using HTTP/3 I couldnt understand this intermittent behavior on mozilla.
Looks every time if I close and reopen the browser, browser is using HTTP/3 as expected.
If I refresh the page multiple times then I do see switch to HTTP/1.1.

-Load-balancer configuration, there are two virtual-host

1. HTTPS with TCP listening on port 443
2. QUIC with UDP listening on port 443
   As per my understanding when access website, for an example "example.com" firefox sends its first HTTP/1.1 request and in the response load-balancer is inserting Atl-Svc "h3=:443", ma=86400 however for subsequent requests firefox is not switching to HTTP/3

From uploaded images you can see the different, working scenario and non working scenario(both cases load-balancer insert Alt-Svc).
I am using firefox 121.0a1
All HTTP/3 and QUIC related configuration are enabled in firefox
Using self-signed certificate
Domain Name is not registered. (added in /etc/hosts to point the IP of Load-balancer virtual-host)

Actual results:

HTTP/3 is intermittently working, which means sometime browser switch the request to HTTP/1.1

Expected results:

Browser should always use HTTP/3

Comment 1

[kirukaa]

Attachment: log.txt-main.1920.moz_log.zip

Comment 2

[Daniel Bodea [:danibodea]]

Setting component to CORE Networking. Please set a more appropriate one if incorrect.
Confirming it will take more than my current understanding of networking (or Quic), but hopefully, the logs will suffice as confirmation.
Thank you for the report!

Comment 3

[Manuel Bucher [:manuel]]

Copy of kershaw's investigation from #neqo:mozilla.org:

kirukan: Based on the log you sent, I've seen that there were some requests using HTTP/3, and than after a while, we received an error from the server.

2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/neqo_http3::* [neqo_http3::connection_client] [Http3 client] check_connection_events - event StateChange(Closed(Transport(PeerApplicationError(514)))).
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/neqo_http3::* [neqo_http3::connection] [Http3 connection] Handle state change Closed(Transport(PeerApplicationError(514)))
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp Http3Session::ProcessEvents [this=1daba434a00]
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp Http3Session::ProcessEvents - ConnectionClosed
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp Http3Session::ProcessEvents - ConnectionClosed error=804b0054
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp HttpConnectionUDP::CloseTransaction[this=1daac88aa00 trans=1daba434a00 reason=804b0054]
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp Http3Session::Close [this=1daba434a00]
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp nsHttpConnectionMgr::ReclaimConnection [conn=1daac88aa00]
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/nsSocketTransport STS dispatch [1dac9a25dc0]
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/nsSocketTransport PollableEvent::Signal
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Write 1
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: I/nsHttp Http3Session::~Http3Session 1daba434a00
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp Http3Session::Shutdown 1daba434a00 allowToRetryWithDifferentIPFamily=0
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: D/nsHttp nsHttpHandler::ExcludeHttp2OrHttp3Internal ci=.S........[tlsflags0x00000000]nginx.f5local.net:443 <ROUTE-via nginx.f5local.net:443> {NPN-TOKEN h3}^partitionKey=%28https%2Cf5local.net%29
2023-11-15 07:13:45.576000 UTC - [Parent 1920: Socket Thread]: V/nsHttp nsHttpConnectionMgr::ExcludeHttp3 exclude ci .S........[tlsflags0x00000000]nginx.f5local.net:443 <ROUTE-via nginx.f5local.net:443> {NPN-TOKEN h3}^partitionKey=%28https%2Cf5local.net%29

So, we put the domain nginx.f5local.net into a blocked list and we won't use HTTP/3 for that domain.

and

That error code is a QPACK error, but I can't tell why.

2023-11-15 07:13:45.342000 UTC - [Parent 1920: Socket Thread]: I/neqo_transport::* [neqo_transport::connection] [Client e0d0dec99ae04ad7] ConnectionClose received. Error code: Application(514) frame type 0 reason QPACK decoder stream error

And yes, looks like it's from the load-balancer.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.