SRS will soon stop working :-)

Claude Scarpelli claude at lovelace.infobiogen.fr
Thu Oct 3 05:40:00 EST 1996


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)




More information about the Bio-srs mailing list