Skip to content
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

api: add ETag support #105

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

api: add ETag support #105

wants to merge 1 commit into from

Conversation

rjw57
Copy link
Member

@rjw57 rjw57 commented Nov 21, 2014

Partially addresses #76.

Add basic ETag support for the prediction API. On each request, an ETag is computed by hashing the prediction request with the dataset which would satisfy it. This ETag is then returned via the ETag header to the client. Should a server set the If-None-Match header on the incoming request, it is compared to the computed ETag and, if they match, a 304 response is returned. If ETags match then the prediction is not run and the client is instructed (via the 304 response) to use the cached version.

Note that this does not directly help us with the current UI since the $.ajax() function must have ifModified set explicitly to true to enable caching support. In that case $.ajax() synthesises a fail. (Quite why jQuery people can't let the browser sort out its own caching I don't know.)

I manually verified behaviour with cURL and by hacking the UI as described above. The UI change is not trivial, however, since jQuery lies and claims the request failed if a 304 is returned.

It's expected that ETags would be more useful when the predictor is put behind some sort of caching proxy (e.g. varnish) which understands ETag/If-None-Match.

Add basic ETag support for the prediction API. On each request, an ETag
is computed by hashing the prediction request with the dataset which
would satisfy it. This ETag is then returned via the ETag header to the
client. Should a server set the If-None-Match header on the incoming
request, it is compared to the computed ETag and, if they match, a 304
response is returned. If ETags match then the prediction is not run and
the client is instructed (via the 304 response) to use the cached
version.

Note that this does not directly help us with the current UI since the
$.ajax() function must have ifModified set explicitly to true to enable
caching support. In that case $.ajax() synthesises a fail. (Quite why
jQuery people can't let the browser sort out its own caching I don't
know.)

It's expected that ETags would be more useful when the predictor is put
behind some sort of caching proxy (e.g. varnish) which understands
ETag/If-None-Match.
@rjw57
Copy link
Member Author

rjw57 commented Nov 21, 2014

(Also, note that the ETag calculation here is not intended to be "secure" in a cryptographic sense. If an attacker manages to find a collision, and then sets the If-None-Match, they'll be rewarded with nothing more than a 304.)

@coveralls
Copy link

Coverage Status

Coverage increased (+1.72%) when pulling 63f1942 on rjw57:add-etag into bc93557 on cuspaceflight:master.

@danielrichman
Copy link
Member

See #76, specifically #76 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants