query parameters at the end of the JavaScript file

[NeoAlchemy]

I am starting to find more web pages that are using a query parameters
after the JavaScript file.

Example can be found at www.opensourcefood.com. Within the source
you'll see: <script src="/shared/scripts/common.js?revision=1.6"
type="text/javascript">.

I am trying to see if there is any big deal to this or a best practice
that is starting to creep up in the JavaScript community. If this is
used only as a way to distinguish what file of JavaScript being used
why not append something inside the file? Has anyone else seen this
or know of more reasons to do this?

 

[David Mark]

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

I am trying to see if there is any big deal to this or a best practice
that is starting to creep up in the JavaScript community. If this is
used only as a way to distinguish what file of JavaScript being used
why not append something inside the file? Has anyone else seen this
or know of more reasons to do this?

There is a good reason to put version info in the filename of a static
script (eg common_v1_0.js) so that you can make use of the Expires and/
or Cache-Control headers. For instance, you could configure your
server to serve all static scripts with an expiration of thirty days
(one year max) and browsers will cache and re-use them without having
to ask the server when they were last modified each time a page is
loaded. When you update a script, you bump the version number to
prevent browsers from using a cached, outdated copy.

 

[Stevo]

I don't like that at all. It indicates that they are using CGI to
serve static script files.

It's not definitely indicating that it's using CGI. You can send that
request to any standard web server and it will totally ignore everything
after the ? and will always return the same static file. It could be
just that they're using it for tracking which version of a some other
file is making requests to common.js. With a bit of server log
processing you can determine for example that you have 50% of requests
to common.js are being made by version 1.6, 30% are being made by 1.5
etc etc. That's one possibility. Or that 1.6 could be to indicate which
version of JavaScript is supported in the browser (script
language="JavaScript1.6") and the site is using it for some kind of
monitoring of browser stats. One thing I've done also with JS requests
is to tack onto the end of it a random number to cache-bust the request
(src='file.js?"+Math.random() .....) which is useful if you know the
file could change at any time and you don't want to rely on the browsers
own cache settings.

 

[David Mark]

It's not definitely indicating that it's using CGI. You can send that
request to any standard web server and it will totally ignore everything

It definitely could indicate that they are using CGI. If not, then
they are doing something really silly.

after the ? and will always return the same static file. It could be
just that they're using it for tracking which version of a some other

Like that.

file is making requests to common.js. With a bit of server log
processing you can determine for example that you have 50% of requests
to common.js are being made by version 1.6, 30% are being made by 1.5
etc etc. That's one possibility. Or that 1.6 could be to indicate which
version of JavaScript is supported in the browser (script
language="JavaScript1.6") and the site is using it for some kind of

The script element would have to be dynamically generated.

monitoring of browser stats. One thing I've done also with JS requests
is to tack onto the end of it a random number to cache-bust the request
(src='file.js?"+Math.random() .....) which is useful if you know the
file could change at any time and you don't want to rely on the browsers
own cache settings.

That makes no sense to me. Every page on the site would have to
download the script every time. If the script is that dynamic, then
it should be served by CGI with appropriate headers to prevent
caching.

 

[Stevo]

It definitely could indicate that they are using CGI. If not, then
they are doing something really silly.

Absolutely, they could be. Which would be dumb.

The script element would have to be dynamically generated.

True. I was just trying to think of something it could be used for and
that's all I came up with ;-)

That makes no sense to me. Every page on the site would have to
download the script every time. If the script is that dynamic, then
it should be served by CGI with appropriate headers to prevent
caching.

It was only one page, not every page on the site and I only had to do it
because even with all the headers set to not cache and with a short time
to live, some browser configs were still not reloading it, instead using
a cached version and so the user wasn't getting what they wanted (the
updated file). Of course these days I'd do an XHR call to get the info
rather than reading a dynamically updated .js file. It was the 90's,
they were wild and crazy times.

 

[Richard Cornford]

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.

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.

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 some were
changed) you would not want the already cached versions used when the
visitor accessed dynamic pages that employed the features that had been
changed. So you update the version number in the script elements (with
an application wide-variable if they are dynamically generated) and the
browser sees the GET requests as distinct from the last version that it
has cached, so it must download and use the new versions. But form them
on, while the version on the query does not change, it can re-use these
new versions from its cache.

Richard.

 

[Thomas 'PointedEars' Lahn]

Example can be found at www.opensourcefood.com. Within the source
you'll see: <script src="/shared/scripts/common.js?revision=1.6"
type="text/javascript">.

I am trying to see if there is any big deal to this or a best practice
that is starting to creep up in the JavaScript community. If this is
used only as a way to distinguish what file of JavaScript being used
why not append something inside the file?

You mean something like a version number?

Has anyone else seen this or know of more reasons to do this?

Possible reasons I can think of:

1. Trying to work around locally cached script resources with different
URIs for the same server resource. Implementing proper cache control
via specified and well-supported HTTP headers would be more reasonable
than that.

2. Using server-side programming to generate (parts of) the served script
resource. The query part could indicate to include a different snippet
of code depending on its value.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[Why `/shared/scripts/common.js?revision=1.6'?]

Possible reasons I can think of:

1. Trying to work around locally cached script resources with different
URIs for the same server resource. Implementing proper cache control
via specified and well-supported HTTP headers would be more reasonable
than that.

2. Using server-side programming to generate (parts of) the served script
resource. The query part could indicate to include a different snippet
of code depending on its value.

3. Using the query part as retrieved with window.location.search
to modify client-side script behavior according to the version
number passed, trying to stay compatible to previous versions
that can be retrieved with a different query part.


PointedEars

 

[David Mark]

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.

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

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.

 

[Lee]

NeoAlchemy said:

I am starting to find more web pages that are using a query parameters
after the JavaScript file.

Example can be found at www.opensourcefood.com. Within the source
you'll see: <script src="/shared/scripts/common.js?revision=1.6"
type="text/javascript">.

While your example made your meaning clear, you should, for your
own benefit, try to express technical questions more precisely.

There are no query parameters at the end of the file, or after
the file. They are appended to the end of the file NAME.


--

 

[David Mark]

David Mark said the following on 8/11/2007 5:15 AM:








Are you aware of any browser that doesn't cache a GET request?

With a query tacked onto it? I thought that was the rule (or at least
recommendation), but IE and others violated it for whatever reason.
Problems can arise as some Web sites use GET's that alter data on the
server (which they shouldn't do.)

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.

hope the browser honors

your cache headers.

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

 

[Richard Cornford]

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.)

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).

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.

 

[David Mark]

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.

That is not what I was getting at. I had read somewhere that browsers
are not supposed to cache requests with queries at all. Certainly
I've never heard of one that caches requests without regard to the
query.

[snip]

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).

You lost me there. I don't delete the old versions.

Are we supposed to fill in the blanks? ;-)

I don't know what happened there. I am sure I finished that
sentence. Anyway, it could get into trouble if I relied on queries to
keep things in sync between pages and scripts. If a browser has a
copy of the page cached with ?version=x and the server has a revised
copy of the script that is served as a static file, the browser would
see that there is a newly updated script (assuming no explicit
expiration was indicated in the original's headers), download it for
use with the cached page and create a mismatch.

 

[David Mark]

David Mark said the following on 8/12/2007 3:56 AM:







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.

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.)

 

[David Mark]

David Mark said the following on 8/13/2007 12:48 AM:








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.



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.

It depends on the browser and configuration. The difference between
instant and "almost instant" is easiest to distinguish when the page
has lots of style sheets, scripts, etc. When pulling from the cache,
depending on the files' headers, it is sometimes necessary to open
connections to the server to check if new versions are available. I
am certain there are times (typically when using the back/forward
buttons), that browsers forego all of this and just repaint the page
from memory.