Caching of 'semi' dynamic JavaScript (IIS, ASP, IE6)

[Stuart]

Hi

We have a dynamically created javascript menu (from ASP), which is
customised per user (Have already taken all the static code out into
separate cached .js file)

The size of the 'dynamic' menu content can be as much as 10kB, and the
menu typically does not change for the duration of the user's session
- i.e. it would be nice to get the browser to 'cache' this. It is an
Intranet application, and is typically aimed at IE6 clients only.

Have considered the following strategies

1) Cookies - although the last thing I want is the whole menu coming
back to the server on every HTTP request - but would be useful IF
there is e.g. a header option the cookie to 'send' the cookie (Server
-> Browser) without the browser ever sending it back to the server
(but the browser still being able to 'read' the cookie?)

2) Creating 'dynamic' javascript files - i.e. send the output per user
to a mangled .js file (e.g. with a session ID in the filename), into a
cached js file. Would however need to cleanup the files quite
regularly, and giving IUSR file creation access doesn't seem a good
idea. Would then get the browser to include the JS by generating ASP
along the lines of.
<script language="JavaScript"
src="TempScripts/Menu<%=UserSession%>.js"></script>

Is there any other way?

Second Question : Is there any way to get IE to stop sending up the
HTTP REFERER header up to the server (e.g. RegKey) - this is pretty
pointless on an Intranet App (I know there is a way to do in
NetScape).

Thanks in advance

Stuart

[Jim Ley]

On 27 Sep 2004 08:06:09 -0700, no***@webmail.co.za (Stuart) wrote:

We have a dynamically created javascript menu (from ASP), which is
customised per user (Have already taken all the static code out into
separate cached .js file)
So why not just make the file fullly cacheable? (either for an hour,
or forever, and invalidate the cache when you on the server know it's
no longer valid by changing the referencing URI.) I'm not sure what's
wrong with this approach, I've certainly used it regularly, without
problems.
Second Question : Is there any way to get IE to stop sending up the
HTTP REFERER header up to the server (e.g. RegKey) - this is pretty
pointless on an Intranet App (I know there is a way to do in
NetScape).

Only by stripping it in the client - why is that relevant to you? If
you're really looking to minimise bandwidth as much as you seem, there
are almost certainly better ways, that would depend on what you're
doing of course.

Cheers,

Jim.

[Stuart]

Thanks for the reply Jim

It isn't really a file (yet) - it is dynamically created javascript
from ASP (once per user session). Agreed that would make it fully
cacheable if did write it out once created (but guess would have to
address the security issues below).

The asp creates the script dynamically
for each option in the system
if the current user has access to this menu option, then add it
(via javascript)
next
then also add in user's own shortcuts / preferences etc.

Re : Referrer : Bandwidth is at a premium here - have ~30 users coming
over a 256kbps pipe. Agreed that javascript window.location type links
do hide the referrer, but still have tons of "A HREF" type links which
would otherwise have to change. Would be nice to have some kind of
server header or browser regkey setting which just suppressed IE's
referrer header.

Cheers

Stuart
ji*@jibbering.com (Jim Ley) wrote in message news:<41***************@news.individual.net>...

On 27 Sep 2004 08:06:09 -0700, no***@webmail.co.za (Stuart) wrote:

We have a dynamically created javascript menu (from ASP), which is
customised per user (Have already taken all the static code out into
separate cached .js file)

So why not just make the file fullly cacheable? (either for an hour,
or forever, and invalidate the cache when you on the server know it's
no longer valid by changing the referencing URI.) I'm not sure what's
wrong with this approach, I've certainly used it regularly, without
problems.

Second Question : Is there any way to get IE to stop sending up the
HTTP REFERER header up to the server (e.g. RegKey) - this is pretty
pointless on an Intranet App (I know there is a way to do in
NetScape).

Only by stripping it in the client - why is that relevant to you? If
you're really looking to minimise bandwidth as much as you seem, there
are almost certainly better ways, that would depend on what you're
doing of course.

Cheers,

Jim.

[Jim Ley]

On 28 Sep 2004 00:18:43 -0700, no***@webmail.co.za (Stuart) wrote:

Thanks for the reply Jim

It isn't really a file (yet) - it is dynamically created javascript
from ASP (once per user session). Agreed that would make it fully
cacheable if did write it out once created (but guess would have to
address the security issues below).
No need to write it out to a file to make it cacheable, just add a few
headers and have your ASP check for an IF_MODIFIED_SINCE header, and
an ETAG and only return the data if it's too old, it's only a few
lines or so of ASP.
Re : Referrer : Bandwidth is at a premium here - have ~30 users coming
over a 256kbps pipe.

Minimising requests, ensuring good http 1.1 pipelining (make sure
you've got content-lengths on all your dynamic stuff) using gzip
compression etc. will all be the places to go before you start looking
at knocking 50 bytes out of the request.

Jim.

[Stuart]

Thanks Jim

Did eventually actually write out to a file & does work a treat - this
was easy nuff to do & will clean these up nightly.

Re : Referrer : Yup, already using PipeBoost for compression (but this
is Server -> Browser).

Noted that the referer header is being passed on each .js Include it
processes on the page (even if the server comes back with NOT
MODIFIED) 20 such includes x 60 bytes = 1200 bytes, from browser ->
Server, which isn't compressed.

Guess will have to live with REFERER's then.

Cheers

Stuart

[Jim Ley]

On 29 Sep 2004 05:37:43 -0700, no***@webmail.co.za (Stuart) wrote:

Noted that the referer header is being passed on each .js Include it
processes on the page (even if the server comes back with NOT
MODIFIED) 20 such includes x 60 bytes = 1200 bytes, from browser ->
Server, which isn't compressed.

Remember not to look at simple number of bytes, bandwidth usage is not
as simple as that. - once you've got a packet going it doesn't matter
full of useful bytes or not. an HTTP request fits in one packet
generally, and the referrer won't change this..

Jim.