Thure and SRS service managers,
IUBio archive now is running version 5 as its SRS server.
The standard link to this is, as it was for version 4,
http://iubio.bio.indiana.edu/srs/srsc
or
http://iubio.bio.indiana.edu/srs/
I would prefer to see SRS servers around the world
continue supporting the http://<server>/srs/srsc interface, as it is
now a standard link that other molecular biology software and
services use. FlyBase uses this, some of my other
software does, as does Andy Law's software, and I know that a number of
servers use IUBio's SRS server thru this interface. It was always
my though that the /srs5/ & /srs5bin/cgi-bin/ links of the new version were
just for testing and preliminary deployment.
IUBio does offer /srs5/ and /srs5bin/cgi-bin/ as aliases, but as I
said in a previous note, I don't think these are necessarily the best
choices for a long-term standard interface. Version numbers in it
suggest that lots of links will have to change again with version 6.
If a new common interface is prefered for version 5, I would vote for
something like the plain
http://<server>/srs/
and this simple extension for binaries
http://<server>/srs/bin/wgetz?whatever
or
http://<server>/srsbin/wgetz?whatever
But I still think the /srs/srsc is better as that (a) already
is standard, so no one will need to change links, (b) allows
server maintainers to more easily configure just what srsc is, since
wgetz is the real name of a program. I use srsc as a script now
but will likely change it to an alias for srs/bin/wgetz
To support the current standard query "/srs/srsc?query", I've
just adapted the old srsc script to add the -e option to cause
it to print its data reports, as in "./wgetz -e $*". It should
be simple to convert wgetz to do this directly, and avoid
an extra process call.
Regarding the www-cache technology potential problem, I go along
with your analysis, and think the /cgi-bin/ addition is
an unneccessary overloading of URL syntax, when there are better
server-configurable options available.
> From etzold at embl-heidelberg.de Wed Oct 2 17:30:43 EST 1996
> Article: 316 of bionet.software.srs
> From: Thure Etzold <etzold at embl-heidelberg.de>
> Subject: Re: SRS will soon stop working :-)
>...
>> 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).
>> 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.
>> 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
>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.
>
-- Don
