UWS result URL - is relative URL okay?
Paul Harrison
paul.harrison at manchester.ac.uk
Mon Nov 4 12:57:35 CET 2019
Hi,
the original inspiration behind the interface design of UWS was REST and as such I would say that URLs should be interpreted in the normal
“web browser” way i.e. both relative and absolute URLs should be allowed.
> On 2019-11 -04, at 09:44, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>
> I'd say the current normative reference here is RFC 3986, section 5.
> Which is a couple of pages of fairly dense prose. In order to keep
> that dense prose out of UWS, I'd much prefer if datalink clients
> didn't have to bother with any of it. I mention in passing that
> things have some extra complication in UWS because the result URIs
> are available both from /{jobs}/{job-id} (as part of the <job>
> element) and from /{jobs}/{job-id}/results. Pop quiz: would the
> relative URIs be the same in both cases?
from above the answer would be no.
> If anyone remembers what the xlink magic tried to do or can be
> bothered to read up on it, by all means chime in if that would have
> to be considered here.
I think that the only reason that xlink was used was to adopt the simple URL link semantics of the href attribute into a general XML document (i.e. treat like an HTML href), and not for some of the more specialised xlink capabilities (which have never seen widespread adoption anyway).
Having said this, it is clearly less useful to use relative links if the job document were to be stored offline by the client to refer to later, as then it would also have to remember where it came from. So my position is that clients should be able to interpret relative links, but servers should prefer to issue absolute links.
Regarding the original issue https://github.com/astropy/pyvo/issues/191, I am arguing that if they are going to use relative links then it would not have a job identifier in the href URL, but also that the client should be more acommodating - I am not entirely sure if the associated PR actually properly fixes the general problem here as I think it might be appending the UWS base URL.
Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20191104/8e91c427/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20191104/8e91c427/attachment.p7s>
More information about the grid
mailing list