Arguments in included javascript?

T

Tim Slattery

I've just come across a Javascript tag that looks like this:

<script type="text/javascript"
src="js/headerSelectUi.js?forcerefresh=0001" >
</script>

Is there any possible reason for the argument at the end of the URL?
The included *.js file never references "forcerefresh", and as far as
I know, it wouldn't be possible for it to.
 
M

Martin Honnen

Tim said:
I've just come across a Javascript tag that looks like this:

<script type="text/javascript"
src="js/headerSelectUi.js?forcerefresh=0001">
</script>

Is there any possible reason for the argument at the end of the URL?
The included *.js file never references "forcerefresh", and as far as
I know, it wouldn't be possible for it to.

Well the name of the query string paramter suggests it is used to force
the browser to fetch the document from the server and don't access any
cached document.

Other reasons could of course be that the server is set up to handle the
requested URL with some server side programming language/framework that
then has access to the query string parameters and serves different
script code based on any values passed in.
 
R

Richard Cornford

I've just come across a Javascript tag that looks like
this:

<script type="text/javascript"
src="js/headerSelectUi.js?forcerefresh=0001" >
</script>

Is there any possible reason for the argument at the end of
the URL? The included *.js file never references "forcerefresh",
and as far as I know, it wouldn't be possible for it to.

At least one reason for doing that (likely in a context where the
script element URL was generated by a server-side script) is that you
usually want script source code to be cached by the client as much as
possible, so the server would be sending headers that encourage
caching. However, if the script gets updated you don't want the
browser using the old one from its cache. To achieve a new fetch from
the server, and then the subsequent caching of the retrieved resource
it would only be necessary, in this case, to change the value of -
forcerefresh - from 001 to, say, 002 (or, better, have a sever side
script do it for you, site-wide). When the browser sees the new URL it
does not see its existing cached copy as being the same resource and
so makes a request to the server to get what it thinks is a different
resource, and so loads, uses, and caches the modified script code.

Richard.
 
E

Evertjan.

Tim Slattery wrote on 21 jun 2011 in comp.lang.javascript:
I've just come across a Javascript tag that looks like this:

<script type="text/javascript"
src="js/headerSelectUi.js?forcerefresh=0001" >
</script>

Is there any possible reason for the argument at the end of the URL?
The included *.js file never references "forcerefresh", and as far as
I know, it wouldn't be possible for it to.


If the asp file that is called by the absent .js file,
or the .js file that is made serverside executable, contains:
===============
var myValue = '<% = Request.querystring("forcerefresh") %>';
===============

the vitual .js stream will show:
===============
var myValue = '0001';
===============
 
T

Thomas 'PointedEars' Lahn

Tim said:
I've just come across a Javascript tag that looks like this:

There is no such thing as a "Javascript tag". Perhaps you want to get the
basics right before you start second-guessing other developers?
<script type="text/javascript"
src="js/headerSelectUi.js?forcerefresh=0001" >
</script>

That is an (X)HTML `script' element, with a `type' attribute value of
"text/javascript".
Is there any possible reason for the argument at the end of the URL?

Yes, but it is no argument (no JS/ES method there), but a parameter (value).
The included *.js file never references "forcerefresh", and as far as
I know, it wouldn't be possible for it to.

It isn't. Client-side script code can only use the URI of the document that
it is included by, and perhaps the document that referred to the former, as
a referent.

Possible reasons include, in descending order of likelihood:

1. People who don't have a minimum clue (i.e., people who have either not
read or not understood [1]).

2. People who lack the opportunity or ability to reconfigure their Web
server according to [1] (i.e., people who should LART/switch their
Web hoster or get a minimum clue about their server).

3. People who have identified a broken Web cache that, despite proper cache
controlling headers, would provide the old resource when the parameter
was omitted, and are dependent on their application to work with that
cache. (I would be interested to know what Web cache that is.)

4. People who use the query parameter (not argument, here) to generate a
different version of the same original resource server-side.


PointedEars
___________
[1] <http://www.mnot.net/cache_docs/>
 
E

Evertjan.

Tim Slattery wrote on 21 jun 2011 in comp.lang.javascript:
It would, yes, but it's not ASP, it's a static *.js file.

You cannot know that, Tim, unless in your own case.

In general, the ASP engine can parse files of any extension that the
engine is set to parse, for instance .html or .js [or even .php ;-) ]

Usually I do not bother to do that, but simply do not have the specified
..js file in that directory. The dedicated 404.asp file then detects the
absent file's name and server.transfer-s the parsing to a file that
contains the asp cum clinetside js.

404.asp minimalistic example:

======================
<% 'vbscript
qstr = lcase(Request.ServerVariables("QUERY_STRING"))
if instr(qstr,":80/js1/js.js")>0 then
server.transfer "/js2/js.asp"
end if
%>
<p>This is the "404 error"-page</p>
======================

So any .js file could be the stream-result of an asp-parsed file.
You could not detect that clientside.
 
R

RobG

Well the name of the query string paramter suggests it is used to force
the browser to fetch the document from the server and don't access any
cached document.

Possibly.

It has been an issue here whether version numbers should be included
in the file name or only stored as a parameter within the file (for
those that have a version number internally). Some suggest they
shouldn't and that file modification dates are sufficient to prompt
clients to download updated files. Others disagree, saying it's not
sufficient to ensure updated versions are fetched and also that it
makes debugging file version related issues unnecessarily difficult.

I am in the latter camp - I much prefer to see foo.1.1.3.js or
whatever so that it's obvious which version of the file the client has
without having to open, or even have access to, the file itself. And
of course as file versions are updated, the file name changes so
clients should download and cache the new version appropriately.
 
S

Scott Sauyet

I know I'm going to regret this. :)
There is no such thing as a "Javascript tag".  Perhaps you want to get the
basics right before you start second-guessing other developers?


That is an (X)HTML `script' element, with a `type' attribute value of
"text/javascript".

There is no such thing as an (X)HTML `script' element. Perhaps you
want to get the basics right before you start second-guessing other
developers?

That is either an XHTML `script' element or an HTML `script' element,
in either case with a `type' attribute value of "text/javascript".

-- Scott
 
T

Tim Slattery

Evertjan. said:
Tim Slattery wrote on 21 jun 2011 in comp.lang.javascript:


You cannot know that, Tim, unless in your own case.

Yes I can know that. I'm looking at the code. It's a JEE system, ASP
has nothing whatsoever to do with it. And it's a normal, static,
Javascript file.
 
S

Scott Sauyet

Tim said:
Evertjan said:
Tim Slattery wrote:
 t's not ASP, it's a static *.js file.

You cannot know that, Tim, unless in your own case.

Yes I can know that. I'm looking at the code. It's a JEE system, ASP
has nothing whatsoever to do with it. And it's a normal, static,
Javascript file.


Do you also know then what code is adding the query parameter to the
URL? Is it also being generated within that JEE system?

Is there perhaps something on the server that's tracking the number of
requests for that url? That's one possible rationale that I can come
up with if it's really a static file. Another one, I guess, is simply
to allow the application the ability to change the file on the fly
without worrying about client-side caching.

-- Scott
 
E

Evertjan.

Tim Slattery wrote on 22 jun 2011 in comp.lang.javascript:
Yes I can know that. I'm looking at the code. It's a JEE system, ASP
has nothing whatsoever to do with it. And it's a normal, static,
Javascript file.

You cannot if you include my "unless".

It can be a normal textstream containing Javascript.

The source file can be a static text file,
but the second is not required to produce the first.

My ASP-code is just an example,
any serverside intelligent code execution should be alble to do so.
 
T

Tim Slattery

Scott Sauyet said:
Tim said:
Evertjan said:
Tim Slattery wrote:
 t's not ASP, it's a static *.js file.

You cannot know that, Tim, unless in your own case.

Yes I can know that. I'm looking at the code. It's a JEE system, ASP
has nothing whatsoever to do with it. And it's a normal, static,
Javascript file.


Do you also know then what code is adding the query parameter to the
URL? Is it also being generated within that JEE system?


It's hard-coded in the JSP file. I've never seen anything like it, and
I wondered whether I'd missed something somewhere. Apparently not.
Is there perhaps something on the server that's tracking the number of
requests for that url?

I know our server doesn't do that.
Another one, I guess, is simply
to allow the application the ability to change the file on the fly
without worrying about client-side caching.

Maybe that's what the programmer had in mind. Seems an odd way to go
about it though.
 
E

Evertjan.

Stefan Weiss wrote on 22 jun 2011 in comp.lang.javascript:
That's the reason why we're using a similar parameter. It allows us to
get both: reliable client side caching as long as the script doesn't
change, and one guaranteed refresh when it does. We're doing this for
static and generated scripts.

(PS: "reliable" because we can control the client configuration :)

You would have to change the value of the argument every time by clientside
code to tell the browser to assume and so cache possible different
versions. An easy way is to use the numeric value of new Date(),
but how would you tranfer that to a script source value??

You could also use a serverside value, but why bother, if serverside coding
is available?

Serverside timeout header-directives, like:
<% Response.Expires = -1000 %>
and no-cache parameters should be just as effective ["just" meaning not
100% effective on 100% of the possible browsers, and assuming reasonable
correct client time settings]
 
S

Scott Sauyet

Evertjan said:
Stefan Weiss wrote on 22 jun 2011 in comp.lang.javascript:



You would have to change the value of the argument every time by clientside
code to tell the browser to assume and so cache possible different
versions. An easy way is to use the numeric value of new Date(),
but how would you tranfer that to a script source value??


I think the main point is that until the server-side file changes, we
want the browser to used its cached version of the resource. But if
that file changes, on the next visit the browser should not used the
cached version.

This is a technique that might use, say, build numbers or source code
revision numbers to let the client know whether the cached version is
still relevant.

An alternative is just to use updated file names, but this technique
is often easier to use.

-- Scott
 
T

Thomas 'PointedEars' Lahn

Stefan said:
We used revision numbers from Subversion at first, but then switched to
a separate version indicator, just a number stored in a "JSVERSION" file
on the server. The advantage is that it also works for testing and
debugging of already deployed code. The number is automatically
incremented by the backend every time the scripts are built (or
modified, in debug mode). We don't have to worry about incrementing it
manually.

Strange reasoning. With SVN, the revision number is incremented
automatically on commit, and aside from checking out the deployed revision
to anywhere you can also switch back and forth any existing working copy
with an appropriate `svn update -r $REVISION'. With your current approach
you will have to worry which SVN revision and branch corresponds with which
manual version and which client might have that version, which does not
sound so great an idea.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top