Improve Cache-Control header parsing and handling
mjpieters opened this issue · 1 comments
mjpieters commented
Currently, a Cache-Control header on the request has an effect if it has one of two values: no-cache
or no-store
, in lowercase.
There are two issues with this:
- The header could contain multiple comma-separate directives, and the directives are case-insensitive. The header value should be lowercased, split on commas and stripped on whitespace, then stored as a set, at the very least.
no-cache
andno-store
currently are treated as the same, and their effect is if both have been provided. However the two directives mean different thingsno-cache
should be treated as if the backend has no value for the cache key, but the result can still be stored.no-store
should be used to skip storing the end-point value in the cache. If the backend still had a response stored it can still be used.
We should probably make it configurable if headers are honoured at all, sometimes you really don't want to allow third-party clients to bypass the cache.
Bharat23 commented
I can work on this.
I do have a question on the response header, though.
If either or both no-cache
and no-store
are used, how should the max-age
and Etag
in the response header look?