VOSpace URI question/issue

[Patrick Dowler]

As you may know, CADC.CANFAR operates two vospace services:
- vault is based on RDBMS (nodes) + object store (stored bytes)
- cavern is based on POSIX filesystem and is mountable (sshfs and within
the skaha science platform)

In cavern, users can create directories and files with characters that are
not valid in a URI and some parts of the vospace service layer fails as it
maps a path in the filesystem to a URI (vos URI in this case). The main
offending character at this point is the space character.

The URI spec (https://www.w3.org/Addressing/URL/uri-spec.html) does
describe using encoding to support such things. I can see a way to
allow/support space by storing it unencoded in the persistence (db or fs),
encoding only when I need to create a URI instance in memory, and then
probably writing node documents with unencoded URIs.
Clients have to carefully deal with spaces in URIs while reading a node
document if they construct a URI instance that validates...

The alternative would be for everyone to send node docs encoded and know to
carefully decode them... Not backwards compat. Generally ugh

My understanding is that the VOSpace-2.1 spec relies on a vos uri being a
valid URI and only defines how the "vos" scheme works within that context.
That's certainly a sane thing to do and has worked for years.

Note: this issue does not apply to the case where a URI is passed as a URL
param: eg the uri param when listing children of a container node, or the
param version of sync transfer negotiation... more of an in-process issue
that seems like it could leak into serialization and potentially
incompatible client-server encode/decode cycle.

Thoughts?
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20230413/897524c2/attachment.htm>