[thelist] Optimising code by UA vs. Proxy caches - week 2 (was server-side browser-sniffing a bad idea?)

aardvark roselli at earthlink.net
Mon Dec 10 14:07:48 CST 2001


> From: "George Dillon  <> Evolt!" <evolt at georgedillon.com>
>
> The discussion last week only increased my concern about this proxy
> cacheing thing...

understood... but nothing beats testing it out if you can... i dunno 
how much of an issue it truly is since i don't have many pages 
coded to specific browsers... that's neither good nor bad, just how 
it is with the stuff i do...

> As I understand it, using server-side detection to deliver
> specific-browser-optimised code according to the User-Agent is
> unreliable since if a request comes from behind a proxy the 'visitor'
> will see the page in the proxy's cache and this may not be the one you
> want delivered to their particular browser.  (So, the proxy might
> cache a NN-optimised page and then blindly deliver it to the 90% of
> 'visitors' using MSIE.)

yes, that is a possibility -- it's happened to me, but i don't know 
how many others it might affect...

> Am I out of my mind in contemplating this semi-workaround?:
> 
> a. Do the server-side detection anyway, and deliver the
> browser-optimised page but including some script to define a
> Javascript variable stating which borwser the page is expecting to be
> viewed in e.g. var apage4="IE";
> 
> b. Do a client-side check (browser-sniff using the same algorithm as
> server-side albeit in Javascript).
> 
> c. Compare the client-side & server-side browser-sniff results, and if
> they're different, immediately reload the page adding a time-based
> query-string.

does the browser report *exactly* the same string to both client-
side scripts and in the HTTP headers?  dunno why it wouldn't, but 
who knows what weirdness may exist...

> Obviously this will fail if .js is off, but so would any other method
> I can think of (short of disabling cacheing completely or not doing
> server-side browser optimisation) ...

what about firewalls that eat JS?  or machines locked down without 
any JS capability?

i think the best approach is to avoid browser-specific pages...

now, if that's not an option, before i spend too much time coding 
work-arounds, i'd take some time to poll users and see who this 
issue truly affects -- it may be no one for all you know...

> Questions remaining...
> 
> 1) does simply adding the date/time to the query-string force the
> request to go all the way to the server (i.e. will it succeed in
> bypassing the proxy-cache)?

hmmm.... dunno... guess it depends...

> 2) if/when it does, will the newly requested page get delivered all
> the way back to the visitor as intended or might the proxy somehow
> mangle this as well?

time to start testing, i guess... can't give you definitive answers to 
either of those...





More information about the thelist mailing list