Bug Tracker

Modify

Ticket #8095 (closed bug: fixed)

Opened 3 years ago

Last modified 2 years ago

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:
Blocking: Blocked by:

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.

Change History

comment:1 follow-up: ↓ 2 Changed 3 years ago by jaubourg

  • Status changed from new to closed
  • Resolution set to invalid
  • Component changed from unfiled to ajax

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.

Last edited 3 years ago by jaubourg (previous) (diff)

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 3 years ago by anonymous

Replying to 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.

comment:3 in reply to: ↑ 2 Changed 3 years ago by jaubourg

  • Status changed from closed to reopened
  • Resolution invalid deleted

Replying to anonymous:

Replying to 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.

comment:4 Changed 3 years ago by jaubourg

  • Owner set to jaubourg
  • Status changed from reopened to assigned

comment:5 Changed 3 years ago by jaubourg

  • Status changed from assigned to closed
  • Resolution set to fixed

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

comment:6 Changed 3 years ago by jitter

  • Priority changed from undecided to low
  • Milestone changed from 1.next to 1.5.1

comment:7 Changed 3 years ago by jitter

  • Version changed from 1.4.4 to 1.5

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.