Re: query parameters at the end of the JavaScript file

David Mark said the following on 8/13/2007 12:48 AM:
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.

And without it being cached it would break nearly every - if not every - search engine on the web due to overload on the server of constantly giving the same search out.

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.

Not sure I agree with you there. It doesn't matter if I go from a Google search to 10 pages down and go back 10 pages to get to the Google search (either 10 clicks of Back or the drop down in IE to go back to it), I still get almost instant display. Not because it is "in memory and repainted" but because it gets the file from the cache and has no need to make a request to the server for the file again.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
.

Loading