Re: query parameters at the end of the JavaScript file
- From: "Richard Cornford" <Richard@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 12 Aug 2007 15:19:23 +0100
David Mark wrote:
On Aug 11, 12:14 pm, Randy Webb wrote:<snip>David Mark said the following on 8/11/2007 5:15 AM:On Aug 10, 3:36 am, Richard Cornford wrote:David Mark wrote:
Some browsers will not cache files retrieved with a<snip>
querystring, so this would seem like a crazy thing
to do.
That would be a faulty caching scheme.
Browsers are not supposed to cache GET requests with queries
AFAIK. I am aware that some do. I am not sure what scheme
you are talking about.
Are you aware of any browser that doesn't cache a GET request?
With a query tacked onto it?
An HTTP GET request is as unique as its URI (which include scheme/protocol, server and port, by implication if not literally included in the URI). HTTP 1.1 (RFC 2616) references RFC 2396 ("Uniform Resource Identifiers (URI): Generic Syntax and Semantics,") for its definition of URI, and RFC 2396 makes it very clear that a query string _is_ part of a URI (and that a fragment identifier is not).
The mans that caching GET requests without regard to their URI (including any query string) would be significantly faulty behaviour. And to date I have seen no evidence of any browser's caching system making this mistake.
I thought that was the rule (or at least recommendation),
The misconception that query strings are not part of the URI crops up intermittently.
but IE and others violated it for whatever reason.
They do consider query strings in their caching systems, but they do it because anything else would be faulty behaviour (and virtually unworkable).
Problems can arise as some Web sites use GET's that alter
data on the server (which they shouldn't do.)
That is a different problem. HTTP GET requests are intended to be 'safe' (RFC 2616, section 9.1.1) and specified as being 'idempotent' (specifically: "... the side-effects of N > 0 identical requests is the same as for a single request" RFC 2616, section 9.1.2). ("identical" here would include the query string as differing query strings would make the URIs differ and so the HTTP GET requests would be different.)
It is difficult to see how an HTTP GET request that had the side effect of altering data on the server could be regarded as 'safe', or be likely to achieve 'idempotence'. Caching may make the consequences worse (certainly more unpredictable) but it would not be the cause of the issue, that would remain poor/uniformed design decisions made by whoever wrote the code that make the alterations. (And would depend quite a greater deal on what the alterations were, and what the consequences were of re-receiving the same request for an alteration, or not receiving subsequent requests with the same URI when they were expected. This is, not all alteration producing side effects would violate safeness or idempotence.)
<snip>This is done (mostly) precisely because browsers do consider
the query string when caching the results of HTTP GET requests.
It is a simple scheme; suppose you have a site/application that
has many javascript files. You would (mostly) want these cached
by the browser (as they will not change in the short term), but
if they were changed (or
I prefer to put the version in the filename ...
Which is fine so long as your version control system can cope with associating the previous versions with the current version, and preferably do the version number changing as you modify the file. And you have a scenario where you are not delivering files/resources/scripts to a remote server where you may have to delete the provision versions from the server by name (rather than delivering new versions that overwrite the old versions when copied to the corresponding locations).
<snip>
As far as I can tell, this method will work regardless of whether
browsers or proxies obey the cache headers. Where it would get in
trouble is if
Are we supposed to fill in the blanks? ;-)
Richard.
.
- Follow-Ups:
- Re: query parameters at the end of the JavaScript file
- From: David Mark
- Re: query parameters at the end of the JavaScript file
- References:
- query parameters at the end of the JavaScript file
- From: NeoAlchemy
- Re: query parameters at the end of the JavaScript file
- From: David Mark
- Re: query parameters at the end of the JavaScript file
- From: Richard Cornford
- Re: query parameters at the end of the JavaScript file
- From: David Mark
- Re: query parameters at the end of the JavaScript file
- From: Randy Webb
- Re: query parameters at the end of the JavaScript file
- From: David Mark
- query parameters at the end of the JavaScript file
- Prev by Date: Re: Is it not well to extend Object.prototype derictly?
- Next by Date: Re: Distinguishing Mac OS X Versions
- Previous by thread: Re: query parameters at the end of the JavaScript file
- Next by thread: Re: query parameters at the end of the JavaScript file
- Index(es):
Relevant Pages
|