StateCache consumer or the StateCache itself does not respect 'Vary' header

[reda-alaoui]

Hello,

We started to use prefer header.
We have a place where we perform 2 subsequent GET on the same uri, first with prefer: return-minimal then with prefer: return-representation. When we use the default ForeverCache, only one request is performed (the first one), and the minimal response is always returned (which is the issue).

Please note that the server returns correctly Vary: prefer in the http response.

The StateCache implementation is unable to verify that the cached state is valid regarding the request headers, since it does not receive them:

export interface StateCache {

  // Missing request headers as parameters?
  get: (uri: string) => State | null;

}

Also, the StateCache consumer does not validate the cached state regarding the Vary header:

  /**
   * Gets the current state of the resource.
   *
   * This function will return a State object.
   */
  get(getOptions?: GetRequestOptions): Promise<State<T>> {

    const state = this.getCache();
    if (state) {
      return Promise.resolve(state);
    }

    //...
  }

Can we either:

• add the GET request options as a second argument to StateCache.get()
  or
• make sure the StateCache consumer validate the cached state regarding the Vary header

If we choose the first option, the StateCache would also need to access the request that lead to the creation of the State (second argument in StateCache.store() or a reference inside State object?) in order to respect https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#varying_responses:

When a cache receives a request that has a Vary header field, it must not use a cached response by default unless all header fields specified in the Vary header match in both the original (cached) request and the new request.

[evert]

"Being better at following HTTP Caching rules" is thing that I've definitely wanted for a while. Also see #21, which has been open for a while.

Supporting Vary / content-negotiation first seems like a good place to start.

A few notes on this:

• It might take some time before I can get to this, so don't hold your breath for now. If you need this, it might require that the contributions come from you. Also, we're open to contracting (but, we will get to this at some point even without funding).
• We should look at the Cache object, which exists in browsers: https://developer.mozilla.org/en-US/docs/Web/API/Cache. Not 100% sure if we can use this for our own purposes, but it's worth a look.
• You are correct that in order to correctly construct cache keys, we will need:
  1. The method
  2. All headers from the request body that appeared in the Vary header.
  3. There's also a default list of headers in requests that influence the cache key, even if they're not in Vary.
  4. The uri

All of this is a bit tricky because we can only know the true cache key after we receive the response.

Sounds like super fun project though.