handling HTTP redirects
dtody at nrao.edu
Wed Jun 4 09:16:40 PDT 2008
Hi All -
Redirects are an important part of the HTTP protocol and I think
need to be supported in the production (2ndgen) protocols which are
HTTP based - hence SSA for example addresses redirects. That said,
as a pragmatic matter much client software may not support redirects
(does not now certainly) hence I suggest we be conservative about
using this feature in actual service implementations to allow client
software time to catch up.
On Wed, 4 Jun 2008, Derriere Sebastien wrote:
> 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:
> 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 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
More information about the registry