<div dir="ltr">Hello,<br><br>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.<br>Currently, the recommended way of doing this is by constructing a /synctrans request with the REQUEST=redirect parameter included:<br><br>curl &quot;<a href="https://server.example.com/vospace/synctrans">https://server.example.com/vospace/synctrans</a><br>    ?TARGET=vos://<a href="http://example.com">example.com</a>~vospace/mydata1<br>    &amp;DIRECTION=pullFromVoSpace<br>    &amp;PROTOCOL=ivo://<a href="http://ivoa.net/vospace/Core#httpsget">ivoa.net/vospace/Core#httpsget</a><br>    &amp;REQUEST=redirect<br>    &amp;SECURITYMETHOD=ivo://<a href="http://ivoa.net/sso#tls-with-certificate">ivoa.net/sso#tls-with-certificate</a>”<br><br>This works just fine and offers a lot of flexibility but is cumbersome.  It is not intuitive to construct, and the URL doesn&#39;t end with the filename, thus causing some clients (such as wget) to name the downloaded file something strange like &#39;tls-with-certificate&#39; because, by default, they ignore the content-disposition header.<div><br></div><div><div>The current 1.1 spec says view=data is deprecated.</div><div><br></div><div>curl &quot;<a href="https://server.example.com/vospace/nodes/mydata1?view=data">https://server.example.com/vospace/nodes/mydata1?view=data</a>&quot;</div><div><br></div><div>If I remember correctly, these are some of reasons for deprecation: </div></div><div>    1)  The behaviour overlaps with what is offered by /synctrans </div><div>    2)  Because the URL ends with ?view=data, it suffers from the wget problem I noted above.</div><div>    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.</div><div><br></div><div>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).<br><br>So, for the purpose of being able to provide users with a single, shareable download URL, I&#39;d like to open the discussion on view=data again.  Some questions:</div><div><br></div><div>- 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.)<br>- Should VOSpace support view=data on the /nodes resource?</div><div>- 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.)</div><div><br></div><div>Cheers,</div><div>Brian</div><div><br></div><div><br></div><br clear="all"><div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font size="2" color="#999999">Brian Major<br><br>Canadian Astronomy Data Centre<br>Centre canadien de données astronomiques<br><br>National Research Council Canada<br>Conseil national de recherches Canada</font></div></div></div><br></div>