Open Bug 2039482 Opened 3 months ago Updated 3 months ago

Consider including `image/webp` in initial `accept` header sent to websites

Categories

(Core :: Networking: HTTP, defect, P3)

defect

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?)

User Story: (updated)

Putting in -next to answer the question of "should we"? Thoughts?

Severity: -- → S3
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(smaug)
Flags: needinfo?(emilio)
Priority: -- → P3
Whiteboard: [necko-triaged][necko-priority-next]

We removed these intentionally in bug 1917177, right?

Flags: needinfo?(emilio)
Keywords: regression
Regressed by: 1917177

It seems we should file a Chrome bug about this at least? Valentin do you know if we filed an issue at the time?

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.

Flags: needinfo?(valentin.gosu)
Flags: needinfo?(smaug)

Set release status flags based on info from the regressing bug 1917177

You need to log in before you can comment on or make changes to this bug.