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 spec requires "item names", i.e. things between the slashes of a path name, to be URI_ENCODEd and that slashes cannot be part of item names. However, I'm not clear on if that means a server should treat encoded slashes the same as unencoded ones. It would seem like that's the case, due to the no-slashes-in-item names requirement.
So to be clear, if a server sees either a GET or a PUT to something like:
It was meant to mean to refer to actual slashes only, not encoded ones.
I think at a high level (like what you type into a browser's address bar), %2F means /, but remoteStorage acts at a low level, so %2F just means %2F.
However, as a client MUST uri-encode item names, and item names MUST NOT contain slashes, then in that case a server should disallow the request, returning something like a 400, right?
Edit: from our own server implementation, I can say that otherwise it's next to impossible to treat slashes correctly between all of one's 1) web server config 2) application router and 3) object storage backend (in case that also uses HTTP). You'd kind of have to double-encode the slash, but when retrieving you don't know what the user actually meant to store earlier. In general, if a user actually wants to store an encoded slash in an item name, then the safest thing to do for them would be a %252F really.
The spec requires "item names", i.e. things between the slashes of a path name, to be URI_ENCODEd and that slashes cannot be part of item names. However, I'm not clear on if that means a server should treat encoded slashes the same as unencoded ones. It would seem like that's the case, due to the no-slashes-in-item names requirement.
So to be clear, if a server sees either a GET or a PUT to something like:
... should that be treated the same as:
The text was updated successfully, but these errors were encountered: