Claude Scarpelli wrote:
>> We have noticed that most (all ?) SRS WWW sites around the world are
> configured such in a way that they are not compatible with the
> emergence of WWW cache.
>> When the browser's client is configured to use a WWW cache, the SRS
> queries issued by the user may be processed with another client
Together with Rob Hooft from the EMBL we have looked at that problem in
We found alltogether three more or less practical options to turn off
1) include /cgi-bin/ in the URL
2) adding a 'Pragma:no-cache' header
3) adding a header with an expiry date, eg, "Expires: Thu, 01 Dec 1994
the first we didn't like since it is quite 'clunky' and forces one to
put all cgi's into
a single directory (not just the one of SRSWWW).
options 2 and 3 both work well ...too well since they turn off cashing
with the consequence that one has to reload always when going a page
back or forward in the
However, consulting the internet standard RFC 1945 we found this:
Applications must not cache responses to a POST request because the
application has no way of knowing that the server would return an
equivalent response on some future request.
Now in SRS5 the pages with user context that are generated by the server
are either POST requests - so they are not cashed - or if obtained by
GET have the user-ID in the URL which makes them unique from pages
retrieved by another user.
All other page obtained by GET without the userId, eg, pages with single
entries, have no
user context and can be safely cached and shared among users.
As far as SRS5 is concerned the system should be safe as it is now.
The only page in SRS4 that is problematic is the one with the URL
since it contains user context information but the userId is not
included in the URL.
So the best would be to add an expiry date + no cache pragma to the
header of just
Thure Etzold | EMBL
E-mail: etzold at embl-heidelberg.de | Postfach 10.2209
Tel: (49) 6221 387529 | 69012 Heidelberg
Fax: (49) 6221 387517 | Germany