Andrew Stewart Gibson

If the above is acceptable then we would expect: 1. A.1. -> call invalidation() 2. B.2. "updateable" returns false -> call invalidation() Which, to my mind makes these two concerns...

ok but the freshening rules specify that you may need to update multiple cached responses. > If the new response contains a strong validator (see Section 2.1 of [RFC7232]), then...

It would seem that strong validators can be per URL - i can't find a limitation on this in the spec. Furthermore, the main use for freshening multiple responses seems...

An efficient public cache would need to know about all such representations, yes. But, I'm not sure that means this library needs to work on the basis of more than...

e.g. starting simple: https://github.com/goofballLogic/http-cache-semantics/commit/c18bbba4577c2193c337e9e028ebfb3266561368

Rules for forming the validation request appear to be very simple (complexity comes with sub-range requests which I note you don't support): https://github.com/goofballLogic/http-cache-semantics/commit/26339d9e7fa69c4578fcbcb6f0b9c43515bf62a5

allowing revalidation via HEAD: https://github.com/goofballLogic/http-cache-semantics/commit/fbfb403c7f8c6e6ba44efb411cae1ae8c812a63b

Ok, here's a compromise proposal for processing response from the revalidation request: 1. freshen() method on CachePolicy, a factory method returning: i. new (freshened or replaced) CachePolicy and Response ii....

1. you are right - will rethink the body part a little 2. criteria - i think a simple has of props to match would suffice (b/c usually it'll just...

Agreed. the criteria concept was to allow efficient querying of databases, but, as you say, it makes correct usage more complex for the user. I'll have a stab at this...