<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As you may know, CADC.CANFAR operates two vospace services: <br></div><div class="gmail_default" style="font-size:small">- vault is based on RDBMS (nodes) + object store (stored bytes)</div><div class="gmail_default" style="font-size:small">- cavern is based on POSIX filesystem and is mountable (sshfs and within the skaha science platform)</div><div class="gmail_default" style="font-size:small"><br></div><div>In cavern, users can create directories and files with characters that are not valid in a URI and <span class="gmail_default" style="font-size:small">some parts of </span>the vospace<span class="gmail_default" style="font-size:small"> 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. <br><br>The URI spec (</span><a href="https://www.w3.org/Addressing/URL/uri-spec.html">https://www.w3.org/Addressing/URL/uri-spec.html</a><span class="gmail_default" style="font-size:small">) does describe using encoding to support </span><span class="gmail_default" style="font-size:small">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. <br></span></div><div><span class="gmail_default" style="font-size:small"></span><span class="gmail_default" style="font-size:small"> Clients have to carefully deal with spaces in URIs while reading a node document if they construct a URI instance that validates...<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">The alternative would be for everyone to send node docs encoded and know to carefully decode them... Not backwards compat. </span><span class="gmail_default" style="font-size:small">Generally ugh</span><br><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">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.<br><br></span></div><div><span class="gmail_default" style="font-size:small">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.<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">Thoughts?<br></span></div><div>--<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div></div>