firefox is ignoring Alt-Svc hearder
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)
Toutes les réponses (9)
Hi, can you file a new bug on https://bugzilla.mozilla.org/enter_bug.cgi ?
Thanks
Ramanan Ganeshu said
Domain Name is not registered. (added in /etc/hosts to point the IP of Load-balancer virtual-host)
Does it make any difference if you change network.dns.use_https_rr_as_altsvc to false in about:config?
TyDraniu said
Hi, can you file a new bug on https://bugzilla.mozilla.org/enter_bug.cgi ? Thanks
This link is redirect to support.mozilla.org
zeroknight said
Ramanan Ganeshu said
Domain Name is not registered. (added in /etc/hosts to point the IP of Load-balancer virtual-host)Does it make any difference if you change network.dns.use_https_rr_as_altsvc to false in about:config?
Its still same.
TyDraniu said
Sorry. https://bugzilla.mozilla.org/enter_bug.cgi
Well ignored that "?" mark in the end in the URL, but what i meant is when i use https://bugzilla.mozilla.org/enter_bug.cgi it redirecting to https://support.mozilla.org/
This is strange, there's no any redirect on my side.
What about this one? https://bugzilla.mozilla.org/
Finally created, https://bugzilla.mozilla.org/show_bug.cgi?id=1864877
I had a discussion with Kershaw in mozilla chat, as per him/her browser is receiving PeerApplicationError(514) after some successful HTTP/3 request/response thus browser put the domain nginx.f5local.net to block-list and not using HTTP/3 anymore for that domain.
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
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
I am separately working with Load-balancer to understand why it has "QPACK decoder stream error". Hope this case can pretty much conclude here.