Implement interface for invalidation after POST/PUT

[kornelski]

A cache MUST invalidate the effective Request URI (Section 5.5 of [RFC7230]) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.

However, a cache MUST NOT invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host part in the effective request URI (Section 5.5 of [RFC7230]). This helps prevent denial-of-service attacks.

A cache MUST invalidate the effective request URI (Section 5.5 of [RFC7230]) when it receives a non-error response to a request with a method whose safety is unknown.

http://httpwg.org/specs/rfc7234.html#invalidation

[goofballLogic]

As far as I am aware, the prototcol for this is simply:

Expose an invalidation() method which returns:

1. If the Method is one of "GET", "HEAD", "OPTIONS", "TRACE", return null
2. Return an object with path, host and calculated full url to invalidate.

Does it need to be any more complex than that?

[kornelski]

That sounds about right.

I haven't thought through revalidation yet, so I wasn't sure if these would overlap.

[goofballLogic]

Spitballing:

A. CachePolicy would expose a method validation() which returns:

1. If the cached response can not be revalidated, return null [stop]
2. Return an object with props indicating
   i. the pre-requisites for revalidation
   ii. the necessary host, path, headers and calculated full URL for the validation request

B. CachePolicy would expose a method freshen( validationResponse ) which returns a RefreshPolicy object exposing:

1. validators - array of validators with which to select responses to freshen (if the new response contains strong/weak validators)
2. updateable( cachedResponse ) which returns true if the specified response should be selected for update
3. responseHeaders( cachedResponse ) which returns the updated, filtered set of response headers after update (following rules http://httpwg.org/specs/rfc7234.html#rfc.section.4.3.4 )

[goofballLogic]

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 (invalidation, revalidation) related, but not overlapping.

[kornelski]

On higher level I'm using this API:

const response = await cache.get(request, modifiedRequest => {
    return http.makeRequest(modifiedRequest);
});

where the callback gets request with added headers for revalidation. Returns promise with updated response. The response is then used to update the cached request.

In such API invalidation is an implementation detail. However, I'm not sure if it's not too inflexible, e.g. it doesn't allow stating preference for last-modified over etag.

[goofballLogic]

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 that strong validator identifies the selected representation for update. All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong validator, then the cache MUST NOT use the new response to update any stored responses.

[kornelski]

Good point. Am I correct thinking that even strong validators are per URL (not per host)?

Since there's satisfiesRequestWithoutRevalidation, let's try one with revalidation:

const x = cache.satisfiesRequest(request, options);

I'm not sure what it should return. It needs to contain revalidation request, but returning null on success is icky, so maybe {satisfies: false, request: {…}}.

or

const result = cache.evaluate(request, options);
if (result.satisfies) {
   return result.responseHeaders();
}
const response = await fetch(result.revalidationRequest());
result.update(response); 
if (result.satisfies) {
   return result.responseHeaders();
} else {
   // dunno?
}

edit: nah, it's terrible.

[goofballLogic]

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 to be related to multiple responses for the same resource but with different header values (other than those specified by the Vary restrictions).

Essentially, there are four possible outcomes when evaluating a request against a cached response:

1. The cached response is fresh
2. The cached response is stale but the request allows it using e.g. "Cache-Control: max-stale=1000"
3. The cached response is stale and must be validated
4. The cached response is stale and cannot be validated

(1) and (2) are covered by satisfiesRequestWithoutRevalidation

I think your second design has some merit - perhaps if we start with a method validationRequest so we can at least do:

if (cachePolicy.satisfiesRequestWithoutRevalidation(request, options)) {
    // proceed with cached response
} else {
   const validationRequest = cachePolicy.validationRequest(); // handles (3)
   if(validationRequest) { 
      const validationResponse = await fetch(validationRequest);
      // mechanism to freshen tbd
   } else {
      // mechanism to invalidate tbd
   }
}

[kornelski]

Yup, that makes sense.

I'd like to hide from users as much logic as possible, so validationRequest could return the original request, even if it doesn't revalidate.

if (cachePolicy.satisfiesRequestWithoutRevalidation(request, options)) {
    return [cachePolicy.responseHeaders(), cachedBody];
} else {
   const validationRequest = cachePolicy.validationRequest();
   const validationResponse = await fetch(validationRequest);

   // equivalent of cachePolicy = new CachePolicy(validationRequest, validationResponse); ?
   cachePolicy.update(validationResponse);

   // So here the cache only needs to know whether to keep the old body or use the new one
    return [cachePolicy.responseHeaders(), cachedOrNewBody];
}

[kornelski]

const validationRequest = cachePolicy.needsRequest(request);
if (validationRequest) {
   const validationResponse = await fetch(validationRequest);

   if (cachePolicy.update(validationResponse)) {
       cachedBody = validationResponse.body;
   }
}
return [cachePolicy.responseHeaders(), cachedBody];

[kornelski]

Oh, validationRequest() needs to know all cached representations to build If-None-Match, and then on 304 response will have to help choose the right one.

[goofballLogic]

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 one. Perhaps that could be a later refinement?

I think it would be enough to make the validation request on behalf of 1 response, and then help in selecting responses which can be freshened.

[goofballLogic]

e.g. starting simple: goofballLogic@c18bbba

[goofballLogic]

Rules for forming the validation request appear to be very simple (complexity comes with sub-range requests which I note you don't support): goofballLogic@26339d9

[goofballLogic]

allowing revalidation via HEAD: goofballLogic@fbfb403