VOSpace 2.1 and view=data

[Dave Morris]

Hi all,

Just to be clear about the requirements, from the session at 
Stellenbosch my understanding was :

     * User wants to be able to send a service request to a VOSpace and 
get back a plain URL that can be used download the content of a node.

     * The download URL provides a way of sharing access to the node 
content.
     * The download URL should work with a simple HTTP GET request.
     * The download URL path should end with a filename based on the node 
name.
     * The download URL should be suitable for listing in a published 
paper.
     * The download URL should be suitable for sending to someone in an 
email.
     * The download URL can be used multiple times by multiple clients.
     * The HTTP response contains the correct file name header based on 
the node name.
     * The HTTP response contains the correct mime-type header based on 
the node content.

Basically, the user wants a simple URL they can share with their friends 
or publish in a paper.

Is that about right ?

Cheers,
Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------

On 2016-06-03 20:21, Brian Major wrote:
> Hello,
> 
> If you were present at the GWS II session in Stellenbosch you will 
> remember
> that the issue of being able to construct a single, shareable VOSpace
> download URL was raised.
> Currently, the recommended way of doing this is by constructing a
> /synctrans request with the REQUEST=redirect parameter included:
> 
> curl "https://server.example.com/vospace/synctrans
>     ?TARGET=vos://example.com~vospace/mydata1
>     &DIRECTION=pullFromVoSpace
>     &PROTOCOL=ivo://ivoa.net/vospace/Core#httpsget
>     &REQUEST=redirect
>     &SECURITYMETHOD=ivo://ivoa.net/sso#tls-with-certificate”
> 
> This works just fine and offers a lot of flexibility but is cumbersome. 
>  It
> is not intuitive to construct, and the URL doesn't end with the 
> filename,
> thus causing some clients (such as wget) to name the downloaded file
> something strange like 'tls-with-certificate' because, by default, they
> ignore the content-disposition header.
> 
> The current 1.1 spec says view=data is deprecated.
> 
> curl "https://server.example.com/vospace/nodes/mydata1?view=data"
> 
> If I remember correctly, these are some of reasons for deprecation:
>     1)  The behaviour overlaps with what is offered by /synctrans
>     2)  Because the URL ends with ?view=data, it suffers from the wget
> problem I noted above.
>     3)  There is ambiguity about the security method.  Just because the
> initial request was over https, you cannot assume a certain security 
> method
> (such as client certificates).  The security method cannot be 
> determined by
> the URL scheme.
> 
> That said, it is a much more attractive URL because it is RESTful (node
> hierarchy is in the URL path) and makes logical assumptions for the
> remaining parameters.  (direction is download, protocol is HTTP or 
> HTTPS,
> yes follow redirects).
> 
> So, for the purpose of being able to provide users with a single, 
> shareable
> download URL, I'd like to open the discussion on view=data again.  Some
> questions:
> 
> - Should VOSpace users require a smart client that understands transfer
> negotiations, or should simple HTTP clients such as curl and wget work?
>  (For downloads only--uploads and server to server transfers are 
> certainly
> too complex.)
> - Should VOSpace support view=data on the /nodes resource?
> - Is there an alternate way of offering a shareable download URL?  (By
> shareable I mean a URL that you can give collaborators and will work 
> for as
> long as the node exists.)
> 
> Cheers,
> Brian