1711622 - Consider explicitly listing image/svg+xml in the Accept header for images (for favicons?)

Status: RESOLVED FIXED

(Core :: Networking, enhancement, P3)

Description

[Daniel Micay]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Steps to reproduce:

Visit https://grapheneos.org/opengraph.png in both Chromium and Firefox with dark mode enabled. The browser fetches /favicon.ico since it's not an HTML page able to configure different icons.

Chromium explicitly advertises support for SVG so it receives an SVG favicon with dark mode support. Firefox only explicitly advertises webp support so user agent sniffing would be required to serve it an SVG favicon in these cases without breaking Safari or assorted bots unable to handle SVG favicons.

Sending image/svg+xml explicitly for /favicon.ico would allow universally serving the SVG rather than only for HTML pages able to configure a list for browsers to choose the best one.

Alternatively, please add support for using Link headers for rel="icon" so it can be used to configure the favicon for non-HTML content. That seems within the scope of https://bugzilla.mozilla.org/show_bug.cgi?id=1409290.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Robert Longson [:longsonr]]

The site uses the wrong order of favicon elements

<link href=/favicon.ico rel=icon><link href=/favicon.svg rel=icon sizes=any type=image/svg+xml>

should be

<link href=/favicon.svg rel=icon sizes=any type=image/svg+xml><link href=/favicon.ico rel=icon>

Perhaps you could contact them and ask them to fix it.

Comment 3

[Daniel Micay]

There's no right or wrong order for icons. Each client implements their own selection algorithm. The /favicon.ico is ordered first there so that legacy clients don't download the /favicon.svg without being able to handle it. Firefox prefers an SVG over an ICO regardless of the order when both are specified in the HTML. Chromium prefers an SVG over an ICO regardless of the order when both are specified in the HTML. For generic clients, the ICO is the most compatible choice and is ordered first. It's also conditionally an SVG anyway.

Firefox already uses the SVG for the HTML pages. I filed the issue about lacking a way to give it an SVG as the favicon for non-HTML content since it provides no way to determine that an SVG is an acceptable response for the hard-wired /favicon.ico request. It seems you're misunderstanding why I filed this. I linked a non-HTML page, not an HTML page. Non-HTML pages do not have any markup like that so I don't really understand why you're bringing it up.

Comment 4

[Daniel Micay]

To clarify, this issue is strictly about non-HTML content where there's no way to change the hard-wired fetching of /favicon.ico. Here are 2 more examples:

https://grapheneos.org/humans.txt
https://grapheneos.org/robots.txt

I linked https://grapheneos.org/opengraph.png as an example of a non-HTML page, not because the image is relevant to this.

This applies to EVERY website, not only https://grapheneos.org/.

Open up a non-HTML file in other website using an SVG favicon for their HTML pages. The browser will request /favicon.ico since non-HTML pages don't have configuration for the favicon. That means there needs to be a way to conditionally serve an SVG for the /favicon.ico request in order to universally use an SVG favicon instead of using it for HTML but not non-HTML. Chromium provides a way to do that without user agent sniffing. Firefox does not. User agent sniffing isn't acceptable for various reasons including clients (crawlers, etc.) unable to handle SVG favicons pretending to be Firefox in their User-Agent header.

I could file another issue using a different site. It's not about any specific page. It's about a generic limitation. Firefox ignores Link headers setting a different icon for non-HTML pages so the only way to use an SVG for those is serving one for /favicon.ico. I'm asking for Firefox to state that it will accept one (it does) so that it can be served one, like Chromium, without (broken) user agent sniffing.

Comment 5

[Daniel Micay]

Or, if you prefer, the example could be a PDF document. Firefox has a hard-wired fetch of /favicon.ico for any non-HTML document, just like other browsers including Chromium and Safari. None of the major browsers actually requires /favicon.ico to be an ICO. The .ico file extension is meaningless to them, as with any other image. They will happily use a PNG, SVG, etc. as long as they support the format.

I'm asking for a way to know that an SVG is an acceptable response for the hard-wired /favicon.ico request in order to consistently use the SVG across a whole site, not only the HTML documents. Chromium provides it via explicit support in the Accept header. Firefox does not. Safari doesn't support SVG favicons and won't have a favicon if /favicon.ico is unconditionally an SVG, and the same goes for most crawlers, etc.

Firefox prefers an SVG over an ICO regardless of the order when both are specified in the HTML. Chromium prefers an SVG over an ICO regardless of the order when both are specified in the HTML.

This was meant to say that Chromium prefers an ICO over and SVG regardless of the order when both are specified in the HTML. It's not relevant to what I filed here though, since it's explicitly not about HTML documents.

Comment 6

[Robert Longson [:longsonr]]

This is likely wontfix then.

Comment 7

[Daniel Micay]

How do you propose using an SVG favicon with dark mode support in Firefox for all content rather than only for HTML pages? Why is this WONTFIX?

Comment 8

[Robert Longson [:longsonr]]

because 99.99% of the web doesn't use SVG so it can't drive adding things to the accept header unfortunately.

Comment 9

[Daniel Micay]

I don't understand the drawback. It's 13 bytes plus a byte for the comma. Chromium's approach of explicitly stating support for each modern image standard without near universal support makes a lot of sense.

Firefox:

Accept: image/webp,/

Chromium:

Accept: image/avif,image/webp,image/apng,image/svg+xml,image/,/*;q=0.8

I don't see any alternative for hard-wired /favicon.ico requests aside from broken user agent sniffing.

https://html.spec.whatwg.org/ and a lot of other sites use SVG favicons too. https://html.spec.whatwg.org/print.pdf is a nice example of the hard-wired /favicon.ico request. If they did provide an ICO, it would be displayed there rather than the SVG. If they only want to use an SVG, they could use the Accept header to provide it there... for Chromium, not Firefox.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

I guess this is the relevant code, and thus this is for networking folks to decide (or perhaps Tim / Andrew, who own imagelib could decide?).

Is there any reason this should be restricted for favicons though? Does chrome really send a different accept header for favicons compared to any other image?

Comment 11

[Daniel Micay]

They send the header for every image request, but it's particularly useful for this hard-wired /favicon.ico request. It would be useful for opening an image directly too so you can send it in the best format. For example, a user might open https://example.org/large-image directly and receive an svg if that's supported. Sometimes your images are linked elsewhere such as users sharing them in a chat, etc. If someone using a browser with support for $MODERN_FORMAT shares a link to it to someone in a browser without it, it would be nice if that link still worked for them. I think doing what Chromium is doing is entirely justified and useful. Firefox seems to agree, for WebP.

Matching Chromium's approach may improve compatibility but it's not the part of this that interests me. I simply want a way to give users a monochrome icon that's not nearly invisible in dark mode across all pages like PDFs, etc. I tried using the Link header but it's ignored. Every browser that I care about supporting has SVG support, but half of them don't support it for favicons. I can't send an SVG unconditionally or Safari, etc. won't have a favicon. I'm trying to get a proper fix and then other people can use the same approach when implementing SVG + dark mode support for favicons. For example, GitHub tries to do the same thing with the favicon color in dark mode but it only works for HTML documents right now and otherwise is stuck with a black icon on black background.

Comment 12

[Master ? [:masterquestionable]]

    [ Quote Daniel Micay @ CE 2021-05-18 15:01:39 UTC:
https://bugzilla.mozilla.org/show_bug.cgi?id=1711622#c11
    For example, a user might open [ https://example.org/large-image ] directly and receive an SVG if that's supported.

    Sometimes your images are linked elsewhere such as users sharing them in a chat, etc.
    If someone using a browser with support for $MODERN_FORMAT shares a link to it to someone in a browser without it, it would be nice if that link still worked for them. ]
<^>    The implication for such, is the site has to store (or generate on-the-fly) different versions of the same image and serve them on need.
    Which most sites wouldn't ever bother.
    And the practice would probably also negate the benefits that "$MODERN_FORMAT" has brought. (mostly data reduction)

    And your example appears to be inclined toward SVG, not images in general. (thus lacks extensibility)

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Chrome
icon: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
image: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

Firefox:
icon: image/avif,image/jxl,image/webp,*/*
image: image/avif,image/jxl,image/webp,*/*

Safari:
icon: */*
image: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

If we were considering adding it only for icon requests, the fix would be to set the Accept header here.

Otherwise, since Chrome and Firefox both send the same headers for both images and favicon loads, we can probably change the ImageAcceptHeader

@Simon, do you have any thoughts? Should we just add image/svg+xml to the image accept header unconditionally?

Comment 14

[Valentin Gosu [:valentin] (he/him)]

For reference:
https://fetch.spec.whatwg.org/#ref-for-header-list-contains%E2%91%A7

Otherwise, the user agent should set value to the first matching statement, if any, switching on request’s destination:
"image"
- image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Comment 15

[Daniel Micay]

(In reply to Master ? [:masterquestionable] from comment #12)

    [ Quote Daniel Micay @ CE 2021-05-18 15:01:39 UTC:
https://bugzilla.mozilla.org/show_bug.cgi?id=1711622#c11
    For example, a user might open [ https://example.org/large-image ] directly and receive an SVG if that's supported.

    Sometimes your images are linked elsewhere such as users sharing them in a chat, etc.
    If someone using a browser with support for $MODERN_FORMAT shares a link to it to someone in a browser without it, it would be nice if that link still worked for them. ]
<^>    The implication for such, is the site has to store (or generate on-the-fly) different versions of the same image and serve them on need.
    Which most sites wouldn't ever bother.
    And the practice would probably also negate the benefits that "$MODERN_FORMAT" has brought. (mostly data reduction)

    And your example appears to be inclined toward SVG, not images in general. (thus lacks extensibility)

Many sites have SVG favicons. A small but growing number of sites use it as part of dark mode support. The main benefits of an SVG are that it's scalable and can support dark mode. Sites can choose to pack multiple images into an ICO to have perfect setups for different sizes, but you can do all that better with SVG if you put in the effort.

It's very easy to conditionally serve it to browsers supporting it for /favicon.ico and nothing forbids doing that. There's a hard-wired request for /favicon.ico when not fetching an HTML page setting it to something else and browsers deliberately allow it to be something other than an ICO which puts the Accept header into the important position of actually describing what they support for this specific request even if they don't do it for others.

I didn't propose changing more than fetching /favicon.ico because there's a specific use case for that which is more interesting than using a better compression format such as lossless WebP instead of PNG. That's already mostly covered, other than SVG. There are likely some cases where an SVG could be served but I expect this is far less common for non-favicon images. It's also generally quite safe to assume SVG is supported but not really for the favicon because even very simple bots fetch the favicon and you probably don't want most of them not ending up with a value they can use. It would be nice not to need to detect Firefox via user agent or some other way particularly since some bots use fake user agent but won't be able to handle SVG for this.

Comment 16

[Simon Pieters [:zcorpan]]

I think adding image/svg+xml to icon and image requests seems good.

I investigated the origin of the spec's Accept value for images (using git blame). I found https://github.com/whatwg/fetch/issues/43#issuecomment-97909717 and https://github.com/whatwg/fetch/commit/d095fdcf284cd36e9ddee526ad6faa6fda4ecc00

I suggest filing a new Fetch spec issue with the current landscape for image Accept values. It's interesting that Firefox and Chrome don't have image/png (anymore).

Comment 17

[Master ? [:masterquestionable]]

    The "/favicon.ico" usage looks like a legacy remnant already superseded by `<link rel="icon">`.
    It's much like the assertion that "/index.html" must point to the index.
    While in fact such file may not even exist or be accessible.

    I don't quite understand your "bot" case: what bots? scrapers like Google?
    In such cases the favicon is likely out of control.

    "better compression format such as lossless WebP instead of PNG."
<^>    Apparent misinformation.
    Under the hood they are not distinctly different.

Comment 18

[Master ? [:masterquestionable]]

    See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1879929

Comment 19

[Daniel Micay]

(In reply to Master ? [:masterquestionable] from comment #17)

    The "/favicon.ico" usage looks like a legacy remnant already superseded by `<link rel="icon">`.
    It's much like the assertion that "/index.html" must point to the index.
    While in fact such file may not even exist or be accessible.

    I don't quite understand your "bot" case: what bots? scrapers like Google?
    In such cases the favicon is likely out of control.

    "better compression format such as lossless WebP instead of PNG."
<^>    Apparent misinformation.
    Under the hood they are not distinctly different.

It's not legacy and cannot be avoided for content that's not a document able to set <link rel="icon" ...> Websites serve more than HTML. Visit https://grapheneos.org/features in Firefox with and without dark mode enabled and you'll see that it's an SVG favicon with dark mode support. Visit https://grapheneos.org/opengraph.png instead and you'll you get a regular ICO favicon without dark mode support in Firefox. In Chromium, you get the SVG favicon in that case too because it sends a usable Accept header. We decided not to do user agent sniffing to work around this Firefox limitation but rather we've requested a proper way to do it. It would help other sites too. You can see where it's done here:

https://github.com/GrapheneOS/grapheneos.org/blob/989a52891c6c05ef19aec34ffa6fd598f040dca8/nginx/nginx.conf#L301-L316

/favicon.ico is simply the default favicon path that's fetched. It doesn't have to be an ICO. The browser sends an Accept header and it's completely valid to return any of the image types it says are supported for that request. If it says it accepts a type it isn't able to handle, that's a browser bug. We need this because not everything is an HTML or other document able to set a different favicon. It's not unusual for people to open an image in a new tab from an HTML page but that's just one example.

I don't quite understand your "bot" case: what bots? scrapers like Google?

Browsers are only one of the clients fetching /favicon.ico. Accept headers works well because the client shouldn't be saying that it accepts SVG if the client can't handle SVG. ICO can be used as a fallback if the Accept header isn't set or better options aren't available. Despite being an awful format, ICO has an advantage over other raster image formats for tiny sizes since you can include multiple. We include 16x16, 24x24, 32x32, 48x48 and 64x64 within the same ICO and rely on brotli/gzip compression to make it a reasonable size (34.5k vs. 2.3k vs 2.6k). They're generated from an SVG rather than hand crafted for each size so there's zero benefit to serving the ICO over a simple vector SVG for us. The main reason we serve an SVG is to support dark mode though.

Apparent misinformation

Lossless WebP providing better compression than PNG is in no way misinformation. PNG uses DEFLATE for compression which is horrible. You get a much more compression for PNG if you disable the DEFLATE compression completely and instead compress it via HTTP compression using Brotli. That's the opposite of how it should work if it was done well.

https://thejh.net/written-stuff/http-brotli-png-compression

Why shouldn't the Accept header advertise support for SVG images? Even Safari still doesn't support SVG favicons, so we'd break the favicon for non-HTML content in Safari if we simply served SVG. We also care about non-browser usage such as search crawlers but also many other uses. Many things rely on fetching /favicon.ico. You don't avoid /favicon.ico by using <link rel="icon" ...> and in fact we'd likely stop using <link rel="icon" ...> at all once Firefox adds this to have perfect consistency between HTML and non-HTML content. This is what we do right now:

<link rel="icon" href="/favicon.ico"/>
<link rel="icon" sizes="any" type="image/svg+xml" href="/favicon.svg"/>

The order matters to make SVG preferred when supported. This is only being done for the sake of Firefox because it doesn't let us do it with the Accept header.

Comment 20

[Daniel Micay]

A website can provide a path such as https://example.com/img/example-lossless-image where they serve PNG as a fallback but use lossless WebP when available. They could similarly have https://example.com/img/example-lossy-image which is JPEG as a fallback but AVIF when supported or WebP if AVIF is not supported. The HTML picture element can sometimes be used instead, but not always. HTML picture element also doesn't work for direct links to the image. As another example, Open Graph supports setting an image for the page via og:image but the consumers of Open Graph metadata support different formats. Accept header is a nice way for them to advertise which Open Graph image formats they support since that standard lacks a way to handle this similarly to the picture element. There are plenty of other use cases where the picture element isn't usable.

In many cases, a raster image is generated from a vector image and it would be nicer to serve the vector image to clients supporting it. We're fine with assuming browsers support SVG for regular images within HTML documents but we can't make that assumption for favicons since Safari doesn't support it and many non-browser clients which are important to us for the favicon don't support it.

There may be some non-Firefox case where using <link rel="icon" ...> still helps so we aren't going to simply remove that without careful research but Firefox is why it was added there in the first place, to work around lack of image/svg+xml in the Accept header for a subset of the content (HTML documents).

Comment 21

[Master ? [:masterquestionable]]

    Websites may serve arbitrary data.
    But what makes use of "/favicon.ico" appears mostly HTML.

    I underestimated the usage for non-web-page type favicon.
    But which shouldn't affect that "/favicon.ico" is legacy and ill-defined.

    See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1865599#c7


    You appear lack of the knowledge of how data compression works in details.
    But which doesn't pertain to the subject, much.
    .
    Side Note:
    On-the-fly generated content cannot compete those generated without time/resource constraint.
    There's hardly much difference: between extreme-compressed PNG and WebP Lossless whatsoever. (similar to alike codecs)


    "The order matters to make SVG preferred when supported."
<^>    What if the `<link rel="icon">` indicated several SVG?
    What if the "href" gives no hint about content type? (as if "/favicon.ico")
    In what order should the icon be preferred..?

    "Why shouldn't the Accept header advertise support for SVG images?"
<^>    Unwanted side-channel.
    Alike: https://bugzilla.mozilla.org/show_bug.cgi?id=1868415#c7
    .
    And why should is not enough convincing.

    Eventually, favicon is a minor thing.
    Even having no favicon at all may be acceptable for many cases. (no functionality impaired)

    Other broken things should be of more significance, considering the compatibility.

Comment 22

[Daniel Micay]

Websites may serve arbitrary data.

Yes, and most websites have images which can be opened as a URL where a favicon is displayed based on /favicon.ico with no way to use a different path.

But what makes use of "/favicon.ico" appears mostly HTML.

It's the other way around. /favicon.ico is fetched by default by web browsers to show the favicon. HTML content can use rel="icon" links to use a different path based on a browser specific algorithm for choosing the best match. In practice, it's not useful beyond providing an SVG favicon with a ICO or PNG fallback. Some clients might not fetch the favicon via the /favicon.ico fallback as browsers do. I'm not aware of an example, but I do have an example of something similar: mobile Chromium uses an Apple touch icon specified in HTML but won't check for it if it's not specified in the HTML because they didn't want to make unnecessary requests for websites not providing one.

/favicon.ico is used as the path for historical reasons. It was originally an ICO file, but today it's a generic image and nearly all clients handle it being a PNG but many don't support SVG. Therefore, there needs to be some way to detect SVG support for the non-HTML use case. It's similar to the header for the Referrer being incorrectly spelled as "Referer" while the newer Referrer-Policy is correctly spelled. It's simply not realistic to fix these kinds of things for the web. The only harm is confusion for web developers unfamiliar with it. /favicon.ico path likely results in continued usage of the legacy, inefficient ICO format where it isn't really necessary.

You appear lack of the knowledge of how data compression works in details.

WebP lossless gets a significantly better compression ratio than PNG. Using zopflipng brings PNG closer but it's definitely not as good. You can see a comparison here:

https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study

Here's another comparison:

https://docs.google.com/spreadsheets/d/1TE5iLE08oV90EqOmFHnzBLwiPtQSs1XAvI3QfoMgKQM/edit#gid=0

You can improve PNG compression by having the internal DEFLATE usage avoid compressing any data and then sending it via transparent brotli compression, which works fine with pre-compression and doesn't need to be done on the fly.

https://thejh.net/written-stuff/http-brotli-png-compression

I don't think it makes sense to continue talking about the merits of more modern image formats here. The issue is about SVG. I simply brought up WebP as another example of a use case for the Accept header. If you don't like the WebP lossless vs. PNG example, then HEIF/AVIF/JXL vs. JPEG can be the example instead.

In what order should the icon be preferred..?

It's defined by the standard and browsers. We order them so that SVG is preferred when supported, which is currently how we use SVG favicons in Firefox for HTML content but we have no option available beyond checking the User-Agent for non-HTML content. Using User-Agent is not a good approach for various reasons that I don't want to get into here. It's not reliable and ideally there would be no User-Agent header but rather only feature detection, and what I'm proposing is providing a way to detect SVG favicon support.

Unwanted side-channel.

It's a constant string that's always the same for favicon requests. It's not a side channel for information. Firefox hasn't frozen the browser version sent in the User-Agent header anyway.

Other broken things should be of more significance, considering the compatibility.

I filed this as a relatively low priority feature request to provide parity with other browsers. The main use case is being able to consistently use an SVG favicon across a site. My title was modified to extend it to cover other images, which makes sense to me. Firefox is currently not setting this header in the way other browsers are doing it. The standard has a baseline recommendation which includes SVG which someone else pointed out above. Implementing this is completely trivial since it simply involves changing a constant string to another constant string in the implementation and the tests. It's not going to take away any significant time from other features.

Comment 24

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1711622 - Use default Accept header for images as specified by fetch standard r=#necko,aosmond,tnikkel,zcorpan

This change is meant to align Firefox with the fetch standard, and to allow
loading SVG images as favicons.

See https://github.com/whatwg/fetch/blob/8dd73dbecfefdbef8f432164fb3a5b9785f7f520/fetch.bs#L4391

Comment 25

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1711622 - Update tests r=#necko

Comment 26

[Valentin Gosu [:valentin] (he/him)]

We should update MDN with the new Accept header values
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values

New image accept header:

image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Or depending on image.avif.enabled and image.jxl.enabled

image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

New document accept header:

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/png,image/svg+xml,*/*;q=0.8

or variations of the following depending on the image prefs

text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/jxl,image/webp,image/png,image/svg+xml,*/*;q=0.8

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c315e89b6e4b
Use default Accept header for images as specified by fetch standard r=tnikkel,necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/877d9c37605a
Update tests r=necko-reviewers,devtools-reviewers,kershaw

Comment 30

[Iulian Moraru]

Backed out for causing reftest failures on accept-image-catchall.html.

• Push with failures

• Failure log

• Backout link

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/643ef26cce28
Use default Accept header for images as specified by fetch standard r=tnikkel,necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/4375d3bfa8fe
Update tests r=necko-reviewers,devtools-reviewers,kershaw

Comment 32

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/643ef26cce28
https://hg.mozilla.org/mozilla-central/rev/4375d3bfa8fe

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Is this something we should call out in the Fx128 relnotes?

Comment 34

[Valentin Gosu [:valentin] (he/him)]

Release Note Request (optional, but appreciated)
[Why is this notable]: The Accept header for images and documents has changed to better match the Fetch standard and other browsers.
[Affects Firefox for Android]: Yes
[Suggested wording]:
The Accept header for images and documents was changed to better align with the Fetch standard.
Image accept header changed from image/avif,image/webp,*/* to image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Document accept header changed from text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 to text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
[Links (documentation, blog post, etc)]:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values
https://fetch.spec.whatwg.org/#document-accept-header-value
https://fetch.spec.whatwg.org/#ref-for-header-list-contains%E2%91%A7

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx128 relnotes.

Comment 36

[Hamish Willee]

FF128 MDN work for this can be tracked in https://github.com/mdn/content/issues/34047

I'm updating https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values.
This says you can update the default value using preference network.http.accept.default

1. I can't find anything about this preference - does it exist, and is it the same as network.http.accept
2. Is the "default" the same as you would get for loading an HTML file - i.e. is default a synonym for "document". The text seems to indicate it is what is used for an address bar or other navigation, which is a bit confusing.

Comment 37

[Valentin Gosu [:valentin] (he/him)]

The relevant prefs are:

• network.http.accept - the override for the document accept header
• image.http.accept - the override for the image accept header

Whether these image formats are accepted and added to the default accept header:

• image.avif.enabled
• image.jxl.enabled

I don't think network.http.accept.default exists anymore.
The HTTP accept header is used for loading a web page or an iframe.