1835100 - Cache-Control: no-cache with an ETag doesn't revalidate when used in an img element

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Kai.Ruhnau]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 Edg/113.0.1774.50

Steps to reproduce:

I have created a repository with the code: https://github.com/Tragetaschen/img-cache-control-issue and a running version of that code https://firefoximgcachecontrol.azurewebsites.net/

I have a backend server that on the same URL (/api) serves a GET request delivering an image with Cache-Control: no-cache and ETag headers and a PUT request that allows changing the delivered image on the backend.

I have web page, where I place an <img src="/api" /> to show the current image and some JavaScript to

1. Toggle the src between the backend URL and a data-URL
2. Send a PUT request to the backend to change the image.

Actual results:

After the PUT, changing the img src continues to show the same image contents. Looking at the Developer Tools' Network tab, it shows clearly that the image is "cached"

Expected results:

At least after the PUT, I expect the browser to revalidate the contents behind the URL using the provided ETag. This is the behavior described in RFC 7234: https://www.rfc-editor.org/rfc/rfc7234#section-4.4

I tested that expectation with Chromium-based browsers as well as Safari on iOS and they show the changed image contents when toggling the image after the PUT

Comment 1

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

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

Comment 2

[Valentin Gosu [:valentin] {{ PTO 2 - 12 April }}]

Pretty sure that this is an issue with imgLoader

Comment 3

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

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Kai.Ruhnau]

When can I expect a substantial response here? It has been four weeks…

Comment 5

[Ina Popescu, Desktop QA]

I've managed to reproduce this issue in Nightly 116.0a1 (2023-07-02) and Firefox 115.0 versions on Windows 10 x64.
Setting this as NEW.