Image Accept: headers in the spec prevent conneg

[wolfbeast]

The fetch spec pretty much mandates that everyone uses:
image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5 for image requests.
This should be adapted to give user agents the possibility to include image formats that might not be universally accepted but preferred, e.g. image/webp or image/apng or image/jxr, and to exclude formats that might not be supported or preferred (e.g. excluding svg support for agents on systems where vector graphics are disproportionately expensive to process), to allow server-driven conneg to happen with servers that support multiple other formats.

As it stands, the spec doesn't allow for this kind of required flexibility, and users agents would not be spec compliant if they indicate their capabilities to servers.

[annevk]

This is #274, no?

[wolfbeast]

Hmm I didn't think that issue describes the exact problem, but to be fair I didn't read every single comment. There is no confusion, after all, but the enforced headers don't provide needed flexibility, and imply support for and preference for certain formats (png and svg) that might not be realistic.

[annevk]

It's a duplicate of the aforementioned issue.

[bathos]

Just a note for others who may land here in the future:

If you’re here due to being puzzled by the seemingly “hard-coded” per-destination accept header values, and perhaps have remained puzzled even after following the link to the duplicate (which acknowledges the confusion, but may not immediately dispel it): the key “ohhhh” thing you (and me until, a moment ago) are likely missing is one thread link deeper, here:

Well, it already says "should" so user agents have some leeway [...]

In other words, because the verb is “should,” Fetch isn’t really preventing agents from setting other values (or none) and agents that currently send other values (which I think is all of em, in practice?) are compliant.