from: https://www.reddit.com/r/firefox/comments/z59e9h/static_assets_load_fine_twice_then_https_fails/

I have this static asset, publicly accessible on my website: https://cms.pinkpigeon.co.uk/static/img/Spinning3DPigeon.gif

In Firefox, I can access this asset the first time and then a second time. The third time, HTTPS fails.

There is no error message or additional information anywhere. Normally, when HTTPS fails, at least Firefox tells me what went wrong, but in this case it looks as though there is no connection being established at all.

I (Kevin) can reproduce this on Firefox Nightly and Beta.

Interestingly, this bug seems to be caused by HTTP/3. If I disable HTTP/3 then it goes away. But it also goes away if I disable disk & memory cache.
I think it may be a server issue, maybe caused by revalidation., that manifests as the server resetting the stream.

The reason it only fails on the 3rd request is:

1. HTTP/2 request, we read Alt-Svc header
2. HTTP/3 request, it works
3. HTTP/3 request with If-Modified-Since header, it fails.

When I try to resend the request in devtools, the request succeeds, the server resets the stream.
The only question is why does this work in Chrome? It is also sending the same header, but their request succeeds. Changing the UA doesn't make any difference.
It could be a server bug entirely, or something caused by how we encode the H3 request.

Hi Kevin, I could not reproduce this today. However, I could reproduce this issue few days ago.
According to this the server has added etag in the response headers. This might have fixed the issue.
Please correct me if I am mistaken.

I just had this fail on 109.0a1 (2022-12-04) (64-bit) Windows 11.

Updating to the latest nightly did not help.

It seems the server is only using HTTP/2 now, and not triggering this bug.

Server maintainer here. As mentioned in the Reddit post, I did some research and started to wonder whether the issue had something to do with this: https://blog.cloudflare.com/introducing-smart-edge-revalidation/

I decided to add etags to all GET requests, which helped, but ultimately didn't fix the issue completely. Why Cloudflare would suddenly only respond via HTTP/2 is a mystery, as I never instructed them to stop using HTTP/3 and looking in the configuration shows it's enabled.

Anyway, the actual solution, in the end, was to add cache-control headers. There have been no issues since.

Would it help if I created either a staging env where the issue can be reproduced, or, possibly even more simply just left the headers off a specific route, which may well cause the failure again?

Hi Adrian, yes, a specific route similar to the original gif file would be quite helpful. Thanks!

Great, I've created an exception for the static file used before: https://cms-staging.pinkpigeon.co.uk/static/img/Spinning3DPigeon.gif

All other routes have cache-control set, and seem to be working fine. This asset, without cache-control is exhibiting the behaviour originally described.

Unassigned from myself as I wont be able to look at this for the next two weeks.

Sunil and I had a look at this, and it seems this is entirely a server side issue.
For some reason the server resets the stream if we send the If-Modified-Since header.

Our main question was why it works in Chrome, and the answer is that Chrome was refusing to use H3 for this site. I don't know if they have a heuristic or something for it, but if we force h3 for the site, it also fails with a protocol error caused by the reset.
google-chrome --origin-to-force-quic-on=cms-staging.pinkpigeon.co.uk:443 https://cms-staging.pinkpigeon.co.uk/static/img/Spinning3DPigeon.gif

So I think we can close this bug as invalid.
I don't think we need a similar heuristic, because as far as I can tell, HTTP3 works on this server, but it doesn't want to talk to us if we send the If-Modified-Since header.

It seems this bug is happening whenever there is a "If-Modified-Since" header, but no "If-None-Match" header.
I reported this to cloudflare and it seems there might be an issue with QPACK on the server side.
Will report back when this is confirmed to be fixed.

This was fixed by changes the cloudflare qpack implementation.