handling HTTP redirects

[Guy Rixon]

Hi Sebastien,

I think that all clients of vr:WebBrowser and vs:ParamHTTP interface  
should expect redirects as these interfaces are "just HTTP". For  
SOAPy interfaces, registered as Vr:WebService, I recommend against  
using redirects as I don't know how well the SOAP toolkits will cope.

Cheers,
Guy

On 4 Jun 2008, at 16:16, 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:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20080604/26c4ae52/attachment-0003.bin>