Identifiers in VOSpace

Wed Jun 21 10:56:58 CEST 2017

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.