You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The path claim intends to limit the areas within a given VO's storage that the token is authorized to read/write from.
However, paths are notoriously tricky as //foo and /foo tend to indicate the same directory in Unix.
Open questions are:
Do we remove extra /?
Do we allow path names such as . and ..?
The underlying question here is whether we adopt a Unix-like model (interpreting these as "parent directory") or a more URL-like model.
URL-like model acknowledges that this lives in the context of an HTTP-centered ecosystem. Unix-like model acknowledges the underlying storage, today, is based on Unix concepts.
What byte values / encoding are allowed in the path?
Honestly, if we had a handy RFC for normalizing paths (maybe the one defining URLs?), I'd be satisfied. I don't think I have a strong opinion here; mostly, I want things to be unambiguous, adhere to rules maintained by someone else, and easy-to-validate.
The text was updated successfully, but these errors were encountered:
The
path
claim intends to limit the areas within a given VO's storage that the token is authorized to read/write from.However, paths are notoriously tricky as
//foo
and/foo
tend to indicate the same directory in Unix.Open questions are:
/
?.
and..
?Honestly, if we had a handy RFC for normalizing paths (maybe the one defining URLs?), I'd be satisfied. I don't think I have a strong opinion here; mostly, I want things to be unambiguous, adhere to rules maintained by someone else, and easy-to-validate.
The text was updated successfully, but these errors were encountered: