Firefox bringing empty content from some URLs - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: September 20, 2023, 07:49:44 am
content: 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/#msg5066524That 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:Status 406 Not AcceptableVersion HTTP/2Transferred 873 B (0 B size)Referrer Policy strict-origin-when-cross-originRequest Priority HighestDNS 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?

author: kultakala
author_rank: Regular Contributor
timestamp: September 20, 2023, 09:42:19 am
content: I dont use firefox but a good idea is always to clear the cache and all cookies.

author: rteodor
author_rank: Frequent Contributor
timestamp: September 20, 2023, 10:48:59 am
content: As far as I know 117 recently got out (few days) to fix a nasty 0-day in webp.Quote from: wikipediaWhat are the request headers ?

author: golden_labels
author_rank: Super Contributor
timestamp: September 20, 2023, 12:01:22 pm
content: rteodor:that’s a response header from the server direction. It does not mean Firefox found something unacceptable, but that thecontent negotiationhas 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.

author: rteodor
author_rank: Frequent Contributor
timestamp: September 20, 2023, 12:09:42 pm
content: Quote from: golden_labels on September 20, 2023, 12:01:22 pmI 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 thatthis ff updatebroke something or it is itself broken.

author: DimitriP
author_rank: Super Contributor
timestamp: September 20, 2023, 04:12:27 pm
content: Update Firefox and reboot twice for good measure.Should come up as version 118.0

author: RoGeorge
author_rank: Super Contributor
timestamp: September 20, 2023, 04:16:36 pm
content: 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 washttps://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:http://HTTP/2 406 Not Acceptabledate: Wed, 20 Sep 2023 14:03:56 GMTcontent-type: text/html; charset=utf-8content-length: 0x-gitlab-meta: {"correlation_id":"some_unigue_ID_numbers","version":"1"}x-request-id: some_unigue_ID_numbersx-runtime: 0.238090gitlab-lb: haproxy-main-24-lb-gprdgitlab-sv: web-gke-us-east1-bcf-cache-status: MISSreport-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-Encodingstrict-transport-security: max-age=31536000x-content-type-options: nosniffserver: cloudflarecf-ray: some_unigue_ID_numbers-OTPX-Firefox-Spdy: h2Request Headers (863 bytes):Code:GET /RoGeorge HTTP/2Host: gitlab.comUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,true;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brDNT: 1Connection: keep-aliveCookie: 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_numbersUpgrade-Insecure-Requests: 1Sec-Fetch-Dest: documentSec-Fetch-Mode: navigateSec-Fetch-Site: noneSec-Fetch-User: ?1

author: rteodor
author_rank: Frequent Contributor
timestamp: September 20, 2023, 07:40:54 pm
content: I put your "Accept" headerCode: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, thenetwork.http.acceptvariable is left empty on one browser. The other one was set to:Code:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8So replacingtruewith*/*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.acceptvariable is inabout:config(type it in the url bar).

author: JohanH
author_rank: Frequent Contributor
timestamp: September 20, 2023, 08:19:48 pm
content: 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.

author: golden_labels
author_rank: Super Contributor
timestamp: September 20, 2023, 09:08:06 pm
content: A bug in JavaScript, turning some non-string value intoTrue?rteodor: ok, I misinterpreted it then seeing both mentioned together.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 20, 2023, 09:33:42 pm
content: 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...

author: RoGeorge
author_rank: Super Contributor
timestamp: September 20, 2023, 09:54:12 pm
content: 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 nearbyimage.http.acceptwas 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.