Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Firefly
-
Labels:None
-
Story Points:6
-
Epic Link:
-
Sprint:SUIT Sprint 2019-02
-
Team:Science User Interface
Description
To make sure we do not serve bad HiPS data do the following:
- Check the return https status of the server. This is really the cause of the problem. The server returned a bad status and saved the html as the properties file.
- Validate the file:
- HiPS property are just like java property files.
- Use magic number for png and jpg
- Hard to validate table files so don't try. If we are not sure of the type don't try to validate.
- Tweek the cacheing parameters. See suggestions from Loi
Cache suggestions from Loi:
According to my reading, in order to do what we want, you want to include these headers in your response:
Cache-Control: must-revalidate max-age=1800 // good for 30mins.. then check for freshness.
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT // example of last modified date of the file served
To validate:
Get the header 'If-Modified-Since’ from the request, then only return the content/body when the content has changed.
Otherwise, return 304.
This check can come in as a ‘HEAD’ or a ‘GET’ request. So, to be safe, override doHead to point to processRequest() to cover all bases.
N.B.: This ticket was triggered based on this IRSA ticket: IRSA-2550
Attachments
Issue Links
- links to
Activity
After Analysis, I now mostly understand the problem. The bug resulted in firefly requesting a png from the backend IRSA server. The IRSA apache server responded with some sort of "not found" status (probably 404).
The BUG: Firefly download the html file produced by the error message instead of a png, and then served the text/html file as the png. It did not check the response code status from the IRSA apache server. By checking the status and not downloading an error message as a png file the problem is fixed.
In addition we are going to add validation of HiPS property files and png files. This does not appear to add much performance impact.
We also are going to tweek the caching parameters we send to the browser. However, the browser caching was really the symptom, not the problem.
A couple more things.
You may want to return the mentioned headers even when it hasn't been modified (304). This may extend the freshness of the cached item. (need to verify)
Also, doHead() should return only headers. So, make sure it's not sending the body.