Identifiers in VOSpace

Tue Aug 15 19:59:31 CEST 2017

Hi Markus,

The use of the question mark (?) instead of the hash (#) was originally
motivated by Norman's note on the use of fragments in URIs:
http://ivoa.net/documents/Notes/URIFragments/20120525/NOTE-URIFragments-1.0-20120525.html

But I think you're right, these particular identifiers don't seem to go
against those recommendations.  Thanks for the clarification.

Brian

On Wed, Jun 21, 2017 at 1:56 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Grid,
>
> While I cannot really comment most of Brian's points, I feel
> compelled to stress one important bit on URI semantics:
>
> On Tue, Jun 20, 2017 at 12:22:50PM -0700, Brian Major wrote:
> > 2.0 synctrans:  ivo://ivoa.net/std/VOSpace/v2.0#/synctrans
> > 2.1 synctrans:  ivo://ivoa.net/std/VOSpace?synctrans-2.1
>
> This really needs to be ivo://ivoa.net/std/VOSpace#synctrans-2.1
> (hash rather than question mark).  The background is that
> synctrans-2.1 refers to something *within* the resource
> ivo://ivoa.net/std/VOSpace: A standard key, in this case.
>
> The URI ivo://ivoa.net/std/VOSpace?synctrans-2.1 would essentially
> mean: Dereference the URI ivo://ivoa.net/std/VOSpace and then make
> some sort of request to it with synctrans-2.1 as a parameter-like
> thing.
>
> This is not different form the way these things work with common HTML
> resources referenced through HTTP URLs.  Consider, for instance, the
> following python CGI:
>
>   import os
>   print("""content-type:text/html\n
>   <html>
>   <p id="constant">Hello World</p><p>{}</p>
>   </html>
>   """.format(os.environ.get("QUERY_STRING", "")))
>
> which I've installed on http://www.g-vo.org/cgi-bin/frag.py [1].
>
> With this,
>
> http://www.g-vo.org/cgi-bin/frag.py#constant
>
> will (conceptually) be the DOM element <p>Hello World</p>
> (referencing something *within* the resource).
>
> http://www.g-vo.org/cgi-bin/frag.py?constant
>
> on the other hand, is the entire document
>
>   <html>
>   <p id="constant">Hello World</p><p>constant</p>
>   </html>
>
>
> The URI
>
> http://www.g-vo.org/cgi-bin/frag.py#random
>
> is a dangling reference, as there's no entity with the id (or <a
> name>) "random" in the resource before the fragment identifier.
>
> The URI
>
> http://www.g-vo.org/cgi-bin/frag.py?random
>
> is perfectly ok (try it if it's not obvious to you what resource it
> references), as is, in this particular case,
>
> http://www.g-vo.org/cgi-bin/frag.py?random#constant
>
> which references the same p element as above. The qualification "in
> this particular case" is because in general, appending a query string
> can of course totally alter the resource returned, so in general
> there's no guarantee that a given fragment will be present in a
> response regardless of the query string[2].
>
> Sorry for posting lots of code, URIs, and angle brackets, but we're
> really doing ourselves a favour if we work with, rather than against
> the URI semantics as planned by the URI creators.
>
>         -- Markus
>
>
> [1] Yes, I'm aware that this code is wide open to XSS, and you
> shouldn't put it onto a server in this form; in the thing
> actually on my server, there's some additional code to plug this,
> irrelevant to this example.
>
> [2] as an example, consider the the CGI script
>
>   import os
>   print("""content-type:text/html\n
>   <html>
>   <p id="{1}">Hello World</p>
>   </html>
>   """.format(os.environ.get("QUERY_STRING", "")))
>
> With it, only URIs of the form ...?<stuff>#<same stuff> would actually
> reference something if there's a fragment identifier.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20170815/5ddd3dad/attachment.html>