Cache response without header if no-cache specifies a field-name

[DavidSint]

The cache control RFC states in section 5.2.2.2:

If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s) listed MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

Specifically, from what I have seen, if a no-cache value appears in the Cache-Control header then it does not appear to be cached, even if the no-cache value specifies a header field. There is an opportunity to abide by the MAY clause in the spec, where the response can still be cached (except for the specified field(s)).

For example, if we see no-cache: set-cookie it is possible, according to the spec, that the response can be cached EXCEPT for Set-Cookie header(s).

I'm opening this issue to look into whether this part of the spec can be implemented in the library so that the response can still be cached.

[kornelski]

This nuance is not implemented in this library.

If you'd like to make a pr for this, I think I'd be fine to add it. I assume it can be implemented without changes to the library's API, and if a cached response has the named header then simply report it needs revalidation.