US (NVO/VAO) opinions on HTTP GET in VOSpace 2.0
mjg at cacr.caltech.edu
Mon Sep 28 17:29:00 PDT 2009
A few weeks back I solicited the NVO Technical WG for their thoughts
on the HTTP GET issue.
To recap, the proposal is to have a simple HTTP GET to retrieve a
file, expressed in a single URL:
without the transfer negotiation that the VOSpace spec currently
requires (the negotiation will remain but this provides a user-
In the absence of the simple HTTP GET, the client will POST a Transfer
representation saying which node they want to get and what protocol
they are using to http://nvo.caltech.edu/vospace/transfers and then
will be get back details of the HTTP GET endpoint to use.
This seems great but to illustrate some concerns, consider the user
who wants to implement VOSpace solely for big data transfers, say
using GridFTP, they would still have to implement this HTTP GET if it
is a mandatory part of the spec but might not support HTTP as a
transport protocol otherwise. There is also the issue that VOSpace 1.x
was specifically defined as transport protocol agnostic and we are now
The overwhelming opinion from the US is in favour of the simple HTTP
GET, mainly on the basis that this particular piece of functionality
will drive >90% of usage (probably 99%). It is less clear, however,
whether this non-negotiated HTTP GET support should be mandatory for
all VOSpace 2.0 services or optional. Since VOSpace 2.0 is inherently
HTTP-based (being RESTful), adding a mandatory HTTP-based transfer
route does not seem to require much more implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vospace