#8095 closed bug (fixed)

Opened January 31, 2011 09:54AM UTC

Closed January 31, 2011 07:00PM UTC

Last modified March 19, 2012 09:24PM UTC

ifModified caching functionality doesn't work if set "cache: false"

Reported by:	Vadim Kiryukhin	Owned by:	jaubourg
Priority:	low	Milestone:	1.5.1
Component:	ajax	Version:	1.5
Keywords:		Cc:
Blocked by:		Blocking:

Description

1. The version(s) of jQuery affected:

version 1.4.4

2. The browser (or browsers) that you are able to reproduce the bug in, including version numbers:

Firefox, Chrome, IE

3. The operating system (or operating systems) you experienced the bug on.

Windows, Linux

4. Step-by-step instructions on how to reproduce the issue, including any required system configuration changes

Set option "cache" to false and option "ifModified" to true.

$.ajax({
...
cache: false,
ifModified:true,
...

});

reproducible: 100%

5. A description of what you expect to happen, and what actually happens

Expected: standard HTTP/1.1 cache exchange with ETag / If-None-Modified / "304 Not Modified" like it works if option ajax "cache" set to "true";

Actual: cache exchange broken; jQuery doesn't send If-None-Modified" to server, so server always send "200 OK" status.

The reason:

a) Option "cache:false" adds a random suffix (which is a current timestamp) to url. So url is never the same.

b) Data from ETag header is saved in hash array where this url is used as a key.

c) Next cycle jQuery generate a new suffix and attached it to url, then checks hash array using this new url a key to get saved value.

obviously, the value doesn't exist, so jQuery doesn't set If-None-Modified" header and server can't issue 304 response.

Solution:

'''don't use s.url as a key. Use a separate variable instead.'''

link to example to see this bug:

http://www.eslinstructor.net/test/jquerybug/bug.html

link to fixed version:

http://www.eslinstructor.net/test/jquerybug/fixed.html

link to php (text), which I use for testing:

http://www.eslinstructor.net/test/jquerybug/get_server_time.php.txt

link to suggested fix (diff )

http://www.eslinstructor.net/test/jquerybug/diff.txt

This solution (diff.txt) is tested for IE, Firefox, Chrome on Windows and Firefox on Linux.

This solution (diff.txt) DOESN'T WORK on Opera on Linux. I think there is another jQuery bug, which prevent processing "304 Not Modified" header correctly in Opera. These two bugs are not related.

Attachments (0)

Change History (7)

Changed January 31, 2011 10:58AM UTC by jaubourg comment:1

_comment0:	I'm quite puzzled at why you would want to set cache to false and have ifModified set to true. Doing so, you're specifically asking ajax to make the response non-cachable yet still expect a "304 Not Modified" response (ie. a cached response). \ \ Current behaviour makes perfect sense: \ 1) hashmap key must be the full url with parameters (your "solution" didn't include the data into the cache_key), \ 2) If and when, cache is set to false, the anti-cache parameter is part of the full url and, thus, data is always pulled from the server and no 304 will ever be issued, which is actually exactly what the cache option is supposed to ensure. \ \ So, if you want to use ifModified and get 304 responses, just don't set the cache option to false. → 1296471614419133
component:	unfiled → ajax
resolution:	→ invalid
status:	new → closed

I'm quite puzzled at why you would want to set cache to false and have ifModified set to true. Doing so, you're specifically asking ajax to make the response non-cachable yet still expect a "304 Not Modified" response (ie. a cached response).

Current behaviour makes perfect sense:

hashmap key must be the full url with parameters (your "solution" didn't include the data into the cache_key),
If and when, cache is set to false, the anti-cache parameter is part of the full url and, thus, data is always pulled from the server and no 304 will ever be issued, which is actually exactly what the cache option is supposed to ensure.

So, if you want to use ifModified and get 304 responses, just don't set the cache option to false.

Changed January 31, 2011 05:47PM UTC by anonymous comment:2

Replying to [comment:1 jaubourg]:

I'm quite puzzled at why you would want to set cache to false and have ifModified set to true. Doing so, you're specifically asking ajax to make the response non-cachable yet still expect a "304 Not Modified" response (ie. a cached response). Current behaviour makes perfect sense: * hashmap key must be the full url with parameters (your "solution" didn't include the data into the cache_key), * If and when, cache is set to false, the anti-cache parameter is part of the full url and, thus, data is always pulled from the server and no 304 will ever be issued, which is actually exactly what the cache option is supposed to ensure. So, if you want to use ifModified and get 304 responses, just don't set the cache option to false.

I set ''cache:false'' to prevent IE to cache Ajax GET REQUESTS, not Respond... There is no relation to "304 Not Modified" as request simply not sent.

Changed January 31, 2011 06:51PM UTC by jaubourg comment:3

resolution:	invalid
status:	closed → reopened

Replying to [comment:2 anonymous]:

Replying to [comment:1 jaubourg]: > I'm quite puzzled at why you would want to set cache to false and have ifModified set to true. Doing so, you're specifically asking ajax to make the response non-cachable yet still expect a "304 Not Modified" response (ie. a cached response). > > Current behaviour makes perfect sense: > * hashmap key must be the full url with parameters (your "solution" didn't include the data into the cache_key), > * If and when, cache is set to false, the anti-cache parameter is part of the full url and, thus, data is always pulled from the server and no 304 will ever be issued, which is actually exactly what the cache option is supposed to ensure. > > So, if you want to use ifModified and get 304 responses, just don't set the cache option to false. I set ''cache:false'' to prevent IE to cache Ajax GET REQUESTS, not Respond... There is no relation to "304 Not Modified" as request simply not sent.

Oh, I see where you're coming from now. You wanna bypass any IE caching while your server-side code ignores the anti-cache parameter jQuery added and delivers proper headers.

Changed January 31, 2011 06:51PM UTC by jaubourg comment:4

owner:	→ jaubourg
status:	reopened → assigned

Changed January 31, 2011 07:00PM UTC by jaubourg comment:5

resolution:	→ fixed
status:	assigned → closed

Fixes #8095. Properly handles the case where browser cache needs to be bypassed while server-side logic still delivers proper 304 responses. Unit test added.

Changeset: f43572d3b86074afc561822b7fd9592e1f05d19b

Changed February 01, 2011 11:58AM UTC by jitter comment:6

milestone:	1.next → 1.5.1
priority:	undecided → low

Changed February 02, 2011 02:44AM UTC by jitter comment:7

version:	1.4.4 → 1.5

Side navigation