763986 - When adding image via dom manipulation, image cache freshness is not checked

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Romain Neutron]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120601175215

Steps to reproduce:

I wrote a javascript that retrieve a piece a dom wich include images with ajax, and append it to body.

This script is triggered by a button click ; the body is empty, then some photos are added to the dom.

Photos as returned by the server with etags,  no content expiration, no max-age (image MUST be revalidate against the server everytime)


Actual results:

The first time the buttons is triggered, some requests checks the server. Is the photos is already in cache with the same etag, a 304 is returned, otherwise a 200.

Next times, photos are considered as cached and fresh (no request to the server are done)


Expected results:

As the cache headers just include Etags, cache validity should be checked everytime the button is clicked to verify the cache freshness

Comment 1

[Boris Zbarsky [:bzbarsky]]

Can you link to a page showing the problem, please?

Comment 2

[Romain Neutron]

Hello,

sorry for the late reply.

Here's a full featured bug reproduction : http://bugzilla763986.preprod.alchemyasp.com/

Comment 3

[Boris Zbarsky [:bzbarsky]]

Thanks.  Looks like imagelib is never actually requesting an HTTP-level revalidate here, presumably because we're hitting its object cache.

I see the same behavior in Safari, for what it's worth.  And in Opera.  So Chrome is the odd man out here.

Now that I see what the page is doing, I believe there are in fact websites that depend on the images NOT being revalidated in this general situation (same image URI, same document).... But over to imagelib for people to check on that.

Comment 4

[Joe Drew (not getting mail)]

Yeah. We made the call a long while ago (to fix real webpages) to explicitly never validate images on the same document.

I'm willing to listen to reason here, but for now I'm calling this a wontfix.

Comment 5

[Romain Neutron]

Hello,

I'm developer for an application which works as a Single Page Application. 

It means the document is loaded once, then everything is done through XMLHTTP and websockets.

Our application acts as strict as possible with web standards (HTTP 1/1, W3C recommendations, ...).

This application manages digital medias online. This medias are supposed to be updated (color correction, rotation ...) and available through HTTP (cool URIs don't change, cache validation is required for such processes, as  everyusers should have an updated version of the media when it's updated server side)

You tell me safari has the same behavior, it is true, a bug report has been filled under BugId #11697852.

I'll check Opera and fill a bug if I confirm what you tell me (I've not check yet).

Comment 6

[Romain Neutron]

Opera bug reported as DSK-368016

Comment 7

[Boris Zbarsky [:bzbarsky]]

Romain, I understand your situation.  The problem is that other websites don't necessarily follow the standards, and there is a large number of sites out there that depend on the images not being revalidated during the lifetime of a document in situations where HTTP says they should be revalidated.  So we can't just revalidate in all situations where HTTP calls for it.

It's _possible_ we could add some sort of special-case here for the case of changed ETag, but that's what it would be: a special-case...

Note, further, that there are various per-document non-HTTP object caches sitting on top of the HTTP cache, which is why you're seeing the behavior you're seeing.

Joe, I do think someone should go through the HTML5 spec for image loading and make sure it describes reality.

Comment 8

[Romain Neutron]

Could you provide more info o this _possible_ special-case ?

It would be great to solve this issue

Comment 9

[Boris Zbarsky [:bzbarsky]]

The special case would be to validate only if the image had an ETag, on the premise that most don't.  Assuming that premise is true....

Comment 10

[Romain Neutron]

Who decide to implement it ? Should I open another ticket with this feature ?

Comment 11

[Romain Neutron]

Hey guys ? Any news ?

Will there any fix soon ?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Probably worth either reopening or better filing a separate bug on the ETag thing.  But it'll need data on how much ETag is actually used on images in the real world...