522463 - XHR with If-Modified-Since header isn't cached, fails to invalidate cache entry for previous request

Status: RESOLVED DUPLICATE of bug 482934

(Core :: DOM: Core & HTML, defect)

Description

[jsmilam]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20091014 Namoroka/3.6b1pre (.NET CLR 3.5.30729)

A XMLHttpRequest for a given URL (for instance '/resource') with a response header of "Cache-Control: max-age=300" is cached in the disk cache as expected. A second XHR is made with an "If-Modified-Since: Wed Dec 31 1969 19:00:00 GMT-0500 (EST)" header. The response to the second request comes back with fresh data, but it is not cached in the disk cache even though a "Cache-Control: max-age=300" header is present. This would be acceptable except when a third request is made for the same URL it returns a stale response from the first XHR made as long as the 300 second max-age has not expired.

Reproducible: Always

Steps to Reproduce:
1. Make a XHR to a URL which will respond with a Cache-Control: max-age=300 header to a URL which will return different results on each request

2. Make a XHR with a Request header of "If-Modified-Since: Wed Dec 31 1969 19:00:00 GMT-0500 (EST)" and a response header of "Cache-Control: max-age=300"

3. Make a XHR matching the first request
Actual Results:  
Responses from the 1st and 3rd XHR are the same because the 3rd request is served from cache. The 2nd request is different from the 1st and second. 

Expected Results:  
I would expect that the 3rd request match the 2nd request. Or that all requests have unique responses.

Comment 1

[John J. Barton]

Attachment: client side html file to reproduce this bug

Comment 2

[John J. Barton]

Attachment: short php to feed the test page

Comment 3

[John J. Barton]

The tests are now online:
http://getfirebug.com/tests/issues/bugzilla/b522463/b522463-XHR-cache-fails.html

Comment 4

[John J. Barton]

Honza, could you take a look at this and double check the cache headers? I plan to ask for blocking here since this is a subtle bug that could make lots of XHR sites fail in ways that would be hard to sort out.

To resummarize: the 3rd GET response comes from the cache of the 1st GET response.

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

Dupe of bug 475156?

Comment 6

[John J. Barton]

I ran the test case from comment 3 on 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091021 Minefield/3.7a1pre
It still fails.

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to comment #6)
> I ran the test case from comment 3 on 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091021
> Minefield/3.7a1pre
> It still fails.

Are you sure the build already contained the fix? It has been landed the same day.

Comment 8

[Honza Bambas (:mayhemer)]

Attachment: test passed screenshot

For me this is fixed.

Comment 9

[Honza Bambas (:mayhemer)]

Correctly this is duplicate of bug 475156.

Comment 10

[jsmilam]

I think the test case only passes now because the test case is faulty. The behaviour on 3.6 was the third request returned the cached response of the first request, while the second request (containing the If-Modified-Since header) returned a fresh response. It seems that on the 3.7 build, where the test is passing, that both the second and third requests return cached responses of the first. I also tried refreshing the browser cache using Cache-Control directives, min-age, min-fresh, no-cache, and max-age. None of them force the cache to be refreshed.

Comment 11

[jsmilam]

Changing line 36 of b522463/b522463-XHR-cache-fails.html from

if( time1 == time3 && time2 != time3 ){

to

if( (time1 == time3 && time2 != time3) || (time1 == time2 && time1 == time3) ){

would be a more correct test case.

Comment 12

[Honza Bambas (:mayhemer)]

-> me

will take a look at this.

Comment 13

[John J. Barton]

Did this get lost?

Comment 14

[Honza Bambas (:mayhemer)]

No, just dropped lower in my todo list.  It has not been approved as blocking so far.

Comment 15

[Benjamin Smedberg]

It's a bug, but not blocker-level.

Comment 16

[Honza Bambas (:mayhemer)]

Releasing for now.  Anyone feel free to take it or let me know this is still a priority and I can take it back.

Comment 17

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I bet this will be fixed when bug 482934 is fixed.

Comment 18

[Thomas Wisniewski]

honza, is this still an issue? The test in the URL in comment 3 is passing for me, even if I use a proxy to alter its script to have the fix suggested in comment 11. Did bug 482934 perhaps end up fixing it as believed?

Comment 19

[Honza Bambas (:mayhemer)]

I think we can duplicated this to bug 482934.