In article <3252B9D0.446B at embl-heidelberg.de>,
Thure Etzold <etzold at embl-heidelberg.de> wrote:
"
" Together with Rob Hooft from the EMBL we have looked at that problem in
" detail:
"
" We found alltogether three more or less practical options to turn off
" caching:
"
" 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
" 16:00:00 GMT"
"
" 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).
No. Just create a cgi-bin directory inside the SRS WWW directory. But
the URL must contained the (9 characters) string /cgi-bin/ somewhere,
not necessarely in the beginning.
I consider that storing the documents in one place, the gif images in
another one, and the cgi-bin in another is a good practice.
"
" options 2 and 3 both work well ...too well since they turn off cashing
" by Netscape
" with the consequence that one has to reload always when going a page
" back or forward in the
" client.
"
I have seen that. Sight:-(. This should be the good solution
though... Just keep it in mind, and use it as soon as browser will no
longer be brain damadged (see below):
" 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.
"
I don't think this paragraph applies to the 'BACK' button. However,
netscape think the opposite.
" 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.
I agree.
" The only page in SRS4 that is problematic is the one with the URL
" http://server/srs/srsc
" 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
" that page.
"
It should be the best... except that it will break Netscape, from a
end-user point of vue (/cgi-bin/ in URL does not break netscape and
its 'back' button).
Put /cgi-bin/ somewhere in the URL appears to me as the only solution
avalaible today.
Regards,
--
------------------------------------------------------------------------------
Claude Scarpelli | Defenestrate: to exit a window
INFOBIOGEN ::= INFOrmatique appliquée à | onscreen. (Time International
l'étude des BIOmolécules et des GÉNomes | Vol 146, No. 20, Nov 13, 1995)
--
------------------------------------------------------------------------------
Claude Scarpelli | Defenestrate: to exit a window
INFOBIOGEN ::= INFOrmatique appliquée à | onscreen. (Time International
l'étude des BIOmolécules et des GÉNomes | Vol 146, No. 20, Nov 13, 1995)
