Re: query parameters at the end of the JavaScript file

On Aug 13, 4:38 am, Randy Webb <HikksNotAtH...@xxxxxxx> wrote:
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.


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.

.

Relevant Pages

  • Re: IIS 6.0 Not Caching Images
    ... There is a known bug where if a 204/304 is fulfilled from the kernel ... regardless if it is fulfilled from the kernel response cache or not. ... request is cached in kernel mode (in addition to using WFetch to make the ... server or not -- you need perfmon to determine. ...
    (microsoft.public.inetserver.iis)
  • CSV merge data via HTTP: redundant downloads?
    ... it sends the same request to the server (thus ... browser cache -- but no love! ... Apparently Word's HTTP request bypasses ...
    (microsoft.public.word.mailmerge.fields)
  • Re: Why One PC right page & the other wrong page
    ... > cache which is looking for those it might just return an Ok to them. ... > IE would have been using if you had only pressed F5) or that the server ... The idea is to make the request look like ... >> and relooked through my old dial up connection I did get the new web ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: query parameters at the end of the JavaScript file
    ... CGI to serve static script files. ... Browsers are not supposed to cache GET requests with queries AFAIK. ... 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 crippled within an hour. ...
    (comp.lang.javascript)
  • Re: query parameters at the end of the JavaScript file
    ... information in the query is a version number. ... Browsers are not supposed to cache GET requests with queries AFAIK. ... Are you aware of any browser that doesn't cache a GET request? ... search engine on the web due to overload on the server of constantly giving the same search out. ...
    (comp.lang.javascript)