Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.