Consider including `image/webp` in initial `accept` header sent to websites
Categories
(Core :: Networking: HTTP, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | wontfix |
| firefox151 | --- | wontfix |
| firefox152 | --- | wontfix |
| firefox153 | --- | fix-optional |
People
(Reporter: dholbert, Unassigned)
References
(Regression, )
Details
(Keywords: regression, webcompat:platform-bug, Whiteboard: [necko-triaged][necko-priority-next])
User Story
user-impact-score:160
When issuing an HTTP request to a website for an HTML file, Chrome has image/webp in the Accept header, whereas Firefox does not.
Perhaps we should consider including image/webp (and other image filetypes?) in our Accept header, for compatibility, to get a step closer to working output in cases like bug 2037800.
In particular, the website in that bug seems to use a web-server extension called "pagespeed" which processes their HTML before it gets sent to the browser. It seems like they author their HTML with some bogus image URLs (with filenames like xcampagne-et-chevaux-1600x622.webp.pagespeed.ic.NKaQ5AjtBx.webp") and then if the browser's initial request includes an accept header with image/webp, then the server rewrites the URL on-the-fly to campagne-et-chevaux-1600x622.webp (stripping off the leading x and the trailing .pagespeed.ic.NKaQ5AjtBx.webp, to produce a URL that will resolves to a real file when requested). Or something along those lines.
(In bug 2037800, you also need a chrome-flavored UA string for this rewriting to happen. That's obviously unfortunate, but we can do that on a case-by-case basis via webcompat interventions. We might consider doing this webp Accept-header tweak more broadly, though, perhaps?)
Updated•3 months ago
|
Comment 1•3 months ago
|
||
Putting in -next to answer the question of "should we"? Thoughts?
Comment 2•3 months ago
|
||
We removed these intentionally in bug 1917177, right?
Comment 3•3 months ago
|
||
It seems we should file a Chrome bug about this at least? Valentin do you know if we filed an issue at the time?
Comment 4•3 months ago
|
||
There has been some cconversation on the fetch spec about what the default document accept header should be, but it has now stalled: https://github.com/whatwg/fetch/issues/274
We could flip the pref and start including image mime types in the document accept header, but I didn't want to rush it in case the spec reached a different conclusion.
I welcome any suggestions in what our next steps should be.
Updated•3 months ago
|
Comment 5•3 months ago
|
||
Set release status flags based on info from the regressing bug 1917177
Updated•3 months ago
|
Updated•3 months ago
|
Description
•