Re: query parameters at the end of the JavaScript file

On Aug 12, 11:58 am, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 8/12/2007 3:56 AM:





On Aug 11, 12:14 pm, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
David Mark said the following on 8/11/2007 5:15 AM:
On Aug 10, 3:36 am, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
David Mark wrote:
On Aug 10, 12:26 am, NeoAlchemy wrote:
I am starting to find more web pages that are using a
query parameters after the JavaScript file.
Example can be found atwww.opensourcefood.com. Within
the source you'll see:
<script src="/shared/scripts/common.js?revision=1.6"
type="text/javascript">.
I don't like that at all. It indicates that they are using
CGI to serve static script files.
It does not. It may indicate that the script elements are being
dynamically generated, but not even that for certain.
As was discussed, I would have been more precise to say that it may
indicate this.
I assume they are static as the only
information in the query is a version number.
Some browsers will not cache files retrieved with a
querystring, so this would seem like a crazy thing to do.
<snip>
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?

There is no "query tacked onto it", the request is part of the URI
itself. The only part of an address that isn't part of the URI itself
are fragment identifiers.

You know what I mean. A URI w/ a query. There was an earlier
misunderstanding in this thread regarding URI's with or without
queries.


I thought that was the rule (or at least recommendation), but IE
and others violated it for whatever reason.

If the recs suggested that you don't cache a URI simply because it was a
GET request then every search engine on the web would become

No. That isn't what I am saying at all. A GET request w/ a query.

crippled
within an hour. You do a search, you get the results, you view the
first link, you click the back button, the GET request wasn't cached, it
is repeated to the server, you start all over.

I don't know what you are talking about. Using the back button may or
may not reference the cache, negotiate with the server about
freshness, etc., depending on the browser's configuration and the
page's headers. Ever notice how back/forward buttons make most pages
appear instantly with seemingly no time to perform any negotiation?
That's because the page and all of its assets were already in memory
and were simply re-painted.





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
[snip]
I prefer to put the version in the filename and use headers to
indicate that the scripts expire at some far-off date (like a year in
the future.) Then the browsers don't have to negotiate with the
server about last modified dates every time the page loads. When the
scripts are updated, the filenames are changed to reflect the new
version, pages are updated to reference the new file and the cached
copy is orphaned.
Then you have to figure out how to get the old HTML file out of my cache
as well that points to the old filename, and

Why? It won't hurt anything as I don't delete the old version of the
script. This is the very reason why I rename the new version, rather
than overwriting the old.

If I read you correctly, you use a version number in the .js file. When

Not in the file. In the filename (eg myscript_v10.js)

the version number gets changed due to a revision, you change the name
of the .js file and reflect the new name in the .html file.

Yes.

Since the
.js file has a new name, it will be loaded from the server. The problem
you have isn't getting the old .js file out of the cache, you have to

I know that isn't a problem for me. The old script is "orphaned",
which some would say is a problem for the user if every site on the
Internet used a similar scheme.

get the old .html file out of my cache since it would point to
oldFile.js instead of newFile.js. Using a querystring parameter suffers
the same flaw as well though.

The old page is supposed to use the old script. If it used the new
script, it may well run into problems (eg there may have been other
changes made to the page to work with the new script.)

.