search

Open-EO / openeo-r-backend

A reference implementation for the openEO core API as a proof-of-concept
Apache License 2.0
6 stars 3 forks source link

URL encoding for dots in file paths required #7

Open m-mohr opened 6 years ago

m-mohr commented 6 years ago

The R server needs the dot in file paths (e.g. /users/me/files/image.png) to be URL encoded. This doesn't follow the RFC standard for characters that need to be URL encoded. Either the R back-end should not need the dot to be URL encoded or - in case this is not possible at all - an issue should be opened for the Core API to request the dot to be URL encoded.

flahn commented 6 years ago

The underlying server implementation (plumber) assumes that if the URL path has a dot and a suffix, it is a static file and not a service. Unless the plumber implementation changes in this regard, the backend won't change in this regard. I guess it the dot-encoding won't be a problem if the file path is provided as query parameter, but i would have to test that to be sure. By the way, the either server needs to URL decode the path argument. Even with the "%2E" replacement for dots, the parsed argument on all servers should be fine. Its really just cosmetics, which the client needs to handle.

m-mohr commented 6 years ago

The JS client can't send %2E in the path in a browser, see https://stackoverflow.com/a/3857067 . This is because all browsers (except Firefox) convert %2E back to a dot during the request. Not sure what we can do here as it all depends on external software. Therefore we might need to change the Core API to have the path in the query.

Edit: Additionally, RFC 3986 says in 2.3 that dots in URLs should not be encoded. Therefore we should not have that specified in the API that dots need to be URL encoded.

flahn commented 6 years ago

Alternatively, we can remove the file feature from the R-Backend and provide it with an alternative Webservice, which also needs to include authentication and authorization via the bearer token. But it will be quite a bit of work and I would post-pone this.

GreatEmerald commented 6 years ago

Why would /users/me/files/image.png be a service and not a static file to begin with? I'd imagine that if it's a service that generates a file on demand, then don't give it an extension to begin with.

m-mohr commented 6 years ago

You probably need to run it as a service as you still need to check the authorization for example. You also still need to accept uploads, like PUT /users/me/files/path/image.png...

GreatEmerald commented 6 years ago

You can have authorisation for regular files (though that's using HTTP authentication, not sure if OpenID Connect would be different). In case of PUT, the file you are uploading doesn't yet exist on the server altogether, and is a static file on your computer; would that still be an issue for plumber?

m-mohr commented 6 years ago

But it could exist. PUT is also for replacing files. And there is also DELETE. Anyway, there is also an issue for NodeJS, see #57. We might want to change it anyway. I think we just need to wait what other back-end providers to try it out. There was not a clear opinion today.

GreatEmerald commented 6 years ago

Yea, I'm just trying to understand why (and to what extent) this is an issue for the R backend...

flahn commented 6 years ago

The issue would be that we are not fully compliant to the API in this regard. And I think we also raised an issue in the API whether or not to treat files as static routes (direct file access using a real dot) or describing the path information as a query parameter, where we would use URL encoding (no dot) (Open-EO/openeo-api#57)