slim
slim copied to clipboard
ImagingDataCommons
Handle web server errors
Follow up on https://discourse.canceridc.dev/t/cant-visualize-cptac-pathology-image/281/10
We may also need to revisit the error handling of Slim and see whether we could further improve it, for example by retrying in case of a 404 error.
I think we should (and I believe we did this for OHIF already, so Slim should be consistent).
cc: @wlongabaugh
From @wlongabaugh:
I will note that while client side retry logic should absolutely be implemented to handle 500 (server) errors, in the case of 400 (client) errors, it should make no difference.
A 404 is strictly speaking a client error, because the client requests a resource that the server couldn't find. However, in our particular case of the single-page application, it appears that the server doesn't return a requested resource that does (or should) exist.
Either way, I agree that we should handle these errors and retry.
OK, I will agree that graceful handling and UI notification of 404s errors where something is missing but which should be there based on expectations derived from e.g. metadata makes sense, but asking the server again after a 404 is a waste if the resources are static. The answer will never change.
Not sure if there is graceful handling of 429 errors yet? Viewer might get that if daily quota is exceeded, and should be redirected to our proxy quota page. And 500 errors are a real concern; I see several a week if a viewer is challenging the proxy service to spool up instances faster than it can handle.
Not sure if there is graceful handling of 429 errors yet? Viewer might get that if daily quota is exceeded, and should be redirected to our proxy quota page.
We have an error handler (see here) and an error page (see here), but we currently only handle DICOMweb errors. We may need to extend that logic to web server errors.
OK, I will agree that graceful handling and UI notification of 404s errors where something is missing but which should be there based on expectations derived from e.g. metadata makes sense, but asking the server again after a 404 is a waste if the resources are static. The answer will never change.
To me the question is whether the status code of the response is actually correct, i.e., whether the server should response indeed with a 404 status code. It appears that there are situations where the single-page application is requesting resources that are specified in the index.html file and really should be there (e.g., JS bundle files), but the web server claims they do not exist and responds with a 404.
It could be possible that an outdated version of the app has been cached in the browser while the web server is serving a newer version. That may result in a situation where a specific file no longer exists server side. In this case, a page reload in the browser is probably the only way to resolve those situations.