handling HTTP redirects

[Derriere Sebastien]

   Hello registry, (CC'ed to DAL, FU2 registry)

   I don't remember this topic being discussed in registry, so I'm
opening the can of worms. The point is how to handle HTTP redirects
in using some of the resources capabilities.
   In the vizier resource descriptions, I can point to some URLs that
serve for example a cone search capability. Example of such query:
http://vizier.u-strasbg.fr/viz-bin/votable/-dtd/-A?-source=J/ApJS/115/1/table2&RA=187.209000&DEC=-1.938000&SR=50.00000
   This accessURL uses the HTTP protocol, and in this case can
return a 302 redirect code indicating the document has moved,
and gives the new location (used in this case for load balancing
to some other machine producing the VOTable).
   Most clients supporting the http protocol will just work fine
(I tested firefox, lynx, wget), and just transparently follow
the redirection and return the final VOTable.
   However, in some cases, what you get is the 302 message
(curl does this, unless you invoke curl -L "http://...").

   In the SSA document, section 8.4 (General HTTP response rules),
this behaviour is explicitly addressed:

 > A server may send an HTTP Redirect message (using HTTP response codes as
 > defined in IETF RFC 2616) to an absolute URL that is different from the
 > valid request URL that was sent by the client. HTTP Redirect causes the
 > client to issue a new HTTP request for the new URL. Several redirects
 > could in theory occur. Practically speaking, the redirect sequence ends
 > when the server responds with a SSA response. The final response shall
 > be a SSA response that corresponds exactly to the original request (or
 > a service exception).

   And I think this is the right thing to do. Because if you try to access
a service via the HTTP protocol, you should use a client that follows the
rules of the HTTP protocol. If not, don't blame the service!

   I've had a few remarks from people thinking the links were broken,
just because they used a library that basically ignored the HTTP status
codes (not receiving "200 OK" does not mean it's an error!).
   Is it reasonable to assume the following for registry resource descriptions? :
"An accessURL pointing to some HTTP address should be handled using
the HTTP protocol". Services should make sure they follow http rules,
and clients too.

Sebastien.
-- 
     _______
    /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
   / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
  /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France