Closed Bug 1865599 Opened 11 months ago Closed 5 months ago

the html img-tag uses a wrong accept-header

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
Firefox 119
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1711622

People

(Reporter: wiliv64644, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15

Steps to reproduce:

I use a URI with content negotiation on it in the src-attribute of an HTML img-tag.

Actual results:

Firefox sends the http request with the accept header: image/avif,image/webp,/.
This then results in a html-page returned from the URI, because the content negotiation could not send image/avif or image/webp, so it results in / and chooses a html response, which cannot be rendered by an img-tag.

Expected results:

If the header would be: image/avif,image/webp,image/*. This would result in a correct response, content negotiation could have chosen: image/png or image/svg+xml which could both be served in my case

the styling in bugzilla did something weird with */* resulting in /, so just to be clear Firefox sends the accept header: image/avif,image/webp,*/*.

This is essentially from bug 1249474 patch, which changed the Accept header from image/png,image/*;q=0.8,*/*;q=0.5 to */*.
We then added image/avif and image/webp later.

According to the bug comments there, the decision to switch to */* was made based on the fact that Safari had been using */*.
But in the latest versions, both Chrome and Safari have image/*.
We could revisit the decision here.

Testcase
data:text/html,<img src="https://bugzilla.mozilla.org/extensions/BugModal/web/throbber.gif">

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

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

Safari 16.6 (18615.3.12.11.2)
Accept: image/webp,image/avif,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Safari Technology Preview Release 183 (Safari 17.4, WebKit 18618.1.5.2)
Accept: 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

Firefox Nightly 121.0a1 (2023-11-20) (64-bit)
Accept: image/avif,image/webp,*/*

Firefox ESR 45 (before bug 1249474)
Accept: image/png,image/*;q=0.8,*/*;q=0.5

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
See Also: → 1249474

If we take the intersection of Chrome and Safari, we could use the following:
Accept: image/avif,image/webp,image/svg+xml,image/*;q=0.8,*/*;q=0.5

or maybe also include image/png, given we had it and also Safari has it?
Accept: image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

:hsivonen, can I have your input?

Flags: needinfo?(hsivonen)

For reference: https://www.w3.org/TR/2011/WD-html5-20110405/embedded-content-1.html#the-img-element
Most important here is that image/* should have precedence over */.
Other thing that is interesting to consider, is that you could give precedence to types that can be rendered eg: Safari includes video/, because they can render that in an img-tag (but which is actually not according to the html-spec).
Single page pdf's (application/pdf) are allowed too, and as far as I know are the only type of content that diverge from the image/* mime-type family.

    Such content negotiation may be outright problematic and in general should be avoided.

    In this case:
    If the URI is supposed to represent an image: `*/*` shouldn't make it return HTML.
    Essentially a server misconfiguration.

In a semantic web world, if you are asking for an image, you might be asking for the metadata representing the image, so if a browser asks */* my default way of handling the request would be to return html, I would return a html-page with the meta information about the image (eg file-size, file-name, resolution, color-depth, copyright, ...) + the actual image. If the browser would be asking image/*, I would only return the image. if the browser would ask application/json, I would return the metadata but in json format.

    The point is: Accept is not as easily manipulable as path query alike.
    And such design tends to make things unnecessarily sophisticated.

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

    Such content negotiation may be outright problematic and in general should be avoided.

    In this case:
    If the URI is supposed to represent an image: `*/*` shouldn't make it return HTML.
    Essentially a server misconfiguration.

That is exactly what content negotiation based on MIME-type is for, if you ignore this, MIME-types become useless in most cases on the web.

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

    The point is: Accept is not as easily manipulable as path query alike.
    And such design tends to make things unnecessarily sophisticated.

Feels like the truth lies in the eye of the beholder here. In the browser it is easy to implement.
And for most developers creating websites nothing will change.

Only if you're creating a site that has content negotiation posibilities which keep the URI the same, but can deliver different outputs based on the MIME-type, you expect the calling browser/app/... to ask for the right type. We use this functionality to send AI-generated descriptions instead of images in the code-base we are working on. So by default we send an image, but if you request with an accept MIME-type of text/plain, you get the generated text. So it would be better that a browser makes clear what to expect.

:hsivonen, do you know what could be done here?

    It is, indeed.

    Maybe easy to implement, not easy to use.
    Eventually, the havoc would be tossed back to end users.

    Similar to request Accept:
    [ Quote Master ? @ CE 2024-01-01 03:09:07 UTC:
https://bugzilla.mozilla.org/show_bug.cgi?id=1872503#c3
    Depending on the response Content-Type to alter browsing experience is acceptable practice. (e.g. the very HTML with "text/html" or "text/plain")
    But for better compatibility and extensibility, certain checks don't have to (and shouldn't) rely on which. ]

How I read the current working of Firefox:

  1. the user wants a picture from the server
  2. the browser says: give a picture of a specific type or just send me anything
  3. the server says: I can' give the specific type, so I'll send a eg text-alternative
  4. then the browser reacts: can't do anything with that

    What the user expects is mostly based on the URI:
    Mostly the extension, or pathname indication.

    Violating such expectation is mostly likely to cause problematic interoperation.

not necessarily, I've worked with an image-server in the past with URIs like: https://imageserver.domain.com/uuid

    For you are already targeting atypical users in such case:
    Those may get the text description are mostly non-browser.

    The linked demonstrates exactly what I suggest.

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Duplicate of bug: 1711622
Resolution: --- → DUPLICATE
Flags: needinfo?(hsivonen)
You need to log in before you can comment on or make changes to this bug.