Ole Moller wrote:
> As the case was I was referring to Andres' citymap which displays 4 images
> depending on input parameters as city, street and house number in germany.
> I must admit I havent checked in my logs but I find it highly unlikely that
> the same search would be performed twice within eg a week (the house number
> taken into consideration).
I don't agree here. It is probably quite likely that if one user looks
up a certain address then he will probably do it shortly again, and it
is also not that unlikely that a friend or otherwise related person also
looks up that same address.
I agree that it is very unlikely that a unrelated person looks up the
same address without some kind of common factor. One quite likely such
factor is if the address has been mentioned on the news or something
similar.
Now, I haven't looked into this specific application, but usually it is
possible to restrict the granularity at higher levels to improve the
possibility that a identical sub-object is requested for a nearby query
to further improve cachability of the application.
I do however agree with what you (or was it someone else) said earlier.
If possible, design the application to use a logical URL path and not
query string if the result is static.
There are two important reasons to this:
1. No query string. The object is like any other static HTTP object.
2. It forces the application developer to design a suitable namespace
for the objects to avoid ambuigity.
Note that in map queries the actual maps probably should have a
namespace, but there is no immediate need to make a namespace for the
surrounding HTML result pages as these usually contains information very
specific to the query or user making the query.
And as on the question of stopping service "abuse" (bypassing ads) there
are techniques for doing this without affecting cachability. Both
cookies and/or referer URLs can be used to very effectively stop any
such "abuses".
--- Henrik Nordstrom Spare time Squid hackerReceived on Tue Mar 09 1999 - 16:49:59 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:11 MST