-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error code for expired file access #379
Comments
This is intentionally not in the API spec, because these signed URLs could be hosted anywhere and the endpoint where the files reside is part of the API, too. Like VITO you could store the results on a S3 bucket and there you can't provide a specific error code and the files will likely just disappear (HTTP 404). So we could only recommend an error code, but clients can't rely on it so the purpose of a pre-defined error code may be limited (i.e. back-ends can just make a custom one). If you still think it's useful, we could add a recommended error code, I'm not advocating against having one, but I'm also not seeing a real advantage of having one. |
In practice all error codes are just recommendations anyway, right? A sloppy backend can choose to raise "500 Internal" everywhere where a better choice is available, and still be "compliant": Line 75 in 81dd248
The standardized error codes are mainly about making the development/debug/maintenance experience better, even if they are un-handled by a client. In that sense it is useful to define this error code, I think. Which alternative would you recommend? |
Yes, correct. I think I'd define it as follows:
and mention it as recommendation in the I realized just now, that the API doesn't say what to do after expiration. I guess it's implicitly clear that |
Interesting, I didn't consider that you can just "refresh" the urls by calling |
see PR #380 I wouldn't do a too short timespan. Usecase is that you can read it with STAC clients, e.g. in QGIS. If that expires too fast, it will get annoying. So I'd do at least an hour... |
sure, order of magnitude of hours is fine too. |
Days or weeks should also be fine, it works for Google Docs, too. |
@laxiwuka is working on implementing signed result download urls (Open-EO/openeo-python-driver#50)
he is also incorporating expiring of download urls, but as far as we know there is no dedicated error code to return when requesting a file that is expired.
Can we add some kind of
FileExpired
error code?The text was updated successfully, but these errors were encountered: