Firefox bringing empty content from some URLs

[RoGeorge]

Starting this weekend, my Firefox brings empty content, but only for certain pages.

For example, gitlab repositories appears as an ampty page, but the main gitlab com page displays OK.

Same for some other URLs, for example it didn't show at all the embedded picture in this reply, it fails silently:
https://www.eevblog.com/forum/chat/stock-electronic-image-fails/msg5066524/#msg5066524
That picture URL is from the TI com domain.  Same as with gitlab, other URLs from the same TI domain are working properly.  Looking at the page source code, it shows no HTML code, it's empty.

It was all working OK last week, only started to misbehave 3-4 days ago.  From my side, I didn't made any changes.
Firefox version is "117.0.1 (64-bit) snap for Ubuntu canonical-002 - 1.0.0", Kubuntu 22.04

- tried disabling all the FF extensions, and it still doesn't work
- for failed gitlab pages, FF console shows network error:  "HTTP/2  406 Not Acceptable"

Code: [Select]

Status                  406 Not Acceptable
Version                HTTP/2
Transferred          873 B (0 B size)
Referrer Policy     strict-origin-when-cross-origin
Request Priority   Highest
DNS Resolution   System
- searched online for a fix, and couldn't find any
- wget works OK for the same URLs that are failing with Firefox
- other Firefox-based browsers, e.g. LibreWolf, are working just fine for the same URLs.

Anybody else having similar issues with Firefox, please?

[kultakala]

I dont use firefox but a good idea is always to clear the cache and all cookies.

[rteodor]

As far as I know 117 recently got out (few days) to fix a nasty 0-day in webp.

406 Not Acceptable The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.

What are the request headers ?

[golden_labels]

rteodor: that’s a response header from the server direction. It does not mean Firefox found something unacceptable, but that the content negotiation has failed. So unrelated to the vulnerability in WebP processing. Hypothetically Firefox could choose to circumvent the problem by returning a fake 406, but I just checked: 117.0.1 displays WebP without issues.

[rteodor]

rteodor: that’s a response header from the server direction. It does not mean Firefox found something unacceptable, but that the content negotiation has failed. So unrelated to the vulnerability in WebP processing. Hypothetically Firefox could choose to circumvent the problem by returning a fake 406, but I just checked: 117.0.1 displays WebP without issues.

I was thinking that FF is sending some malformed request that the server finds unacceptable.

No relation with the WebP other that it was an update a few days ago that might be the culprit. Meaning it is most likely that this ff update broke something or it is itself broken.

[DimitriP]

Update Firefox and reboot twice for good measure.
Should come up as version 118.0 

[RoGeorge]

Thank you all for the help.  I have close to zero skills in debugging this, so for now I am just using LibreWolf instead.

Googled for how to find out the request headers sent by Firefox, and found it should be CTRL+SHIFT+i in almost any browser.  That opens the same debugging page from where it was copied the err 406 message posted before.

This time I've noticed there is an option to show the raw data.  The address tried was https://gitlab.com/RoGeorge.  I've replaced "some_unigue_ID_numbers" what appeared like an ID, just to be sure I'm not posting confidential data.

Response Headers (863 bytes):

Code: [Select]

http://HTTP/2 406 Not Acceptable
date: Wed, 20 Sep 2023 14:03:56 GMT
content-type: text/html; charset=utf-8
content-length: 0
x-gitlab-meta: {"correlation_id":"some_unigue_ID_numbers","version":"1"}
x-request-id: some_unigue_ID_numbers
x-runtime: 0.238090
gitlab-lb: haproxy-main-24-lb-gprd
gitlab-sv: web-gke-us-east1-b
cf-cache-status: MISS
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=some_unigue_very_long_ID_numbers"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}
vary: Accept-Encoding
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
server: cloudflare
cf-ray: some_unigue_ID_numbers-OTP
X-Firefox-Spdy: h2

Request Headers (863 bytes):

Code: [Select]

GET /RoGeorge HTTP/2
Host: gitlab.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,true;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Cookie: cf_clearance=some_unigue_ID_numbers; OptanonConsent=isGpcEnabled=0&datestamp=Sun+Sep+17+2023+11%3A11%3A35+GMT%2B0300+(Eastern+European+Summer+Time)&version=202308.2.0&browserGpcFlag=0&isIABGlobal=false&hosts=&consentId=some_unigue_ID_numbers&interactionCount=1&landingPath=https%3A%2F%2Fabout.gitlab.com%2F&groups=C0001%3A1%2CC0003%3A0%2CC0002%3A0%2CC0004%3A0; preferred_language=en; about_gitlab_active_user=true; _gitlab_session=some_unigue_ID_numbers; event_filter=all; _cfuvid=some_unigue_ID_numbers
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1


[rteodor]

I put your "Accept" header

Code: [Select]

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,true;q=0.8and got 406 too !

Looking at two browsers I have around, the network.http.accept variable is left empty on one browser. The other one was set to:

Code: [Select]

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
So replacing true with */* seems to fix the issue.
Now I do not know what all that means and it is way to late... maybe tomorrow...

NB: network.http.accept variable is in about:config (type it in the url bar).

[JohanH]

The Accept header takes a MIME type (<MIME-type>/<MIME-subtype>). "true" is not a MIME type, AFAIK, so it makes sense that replacing it with */* makes it work.

[golden_labels]

A bug in JavaScript, turning some non-string value into True?

rteodor: ok, I misinterpreted it then seeing both mentioned together.

[SiliconWizard]

Using Firefox 117.0.1 here with KDE Plasma on Wayland, and no problem.

I've experienced more quirks with Thunderbird the last few months, but I bet even fewer people are using it than people using Firefox...

[RoGeorge]

Wow, thank you for pointing to http.accept variables, and for the MIME type issue.  Now gitlab pages are visible again.

I was not sure if I have to copy/paste the entire "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", so I put side by side the settings for the not working FF, and for the working LibreWolf, as in the attachment.  They were both empty.

However, the nearby image.http.accept was shown as edited, though I don't recall manually changing any "accept" variables, I didn't even know they existed until today.  So I reverted it back to its default value (empty).

After that, the gitlab pages started to work. 
No idea if what I did is OK, will make more tries tomorrow.

The jpg from TI (linked in the OP) still doesn't show, but it's too late to investigate why.  Might be caused by something else entirely.

Thanks again for explaining what to look for.