Re: Why should caches and intermediaries ignore If-Match?

["Roy T. Fielding" <[e-mail]>]

On Mar 1, 2017, at 5:49 PM, Tom Bergan <[e-mail]> wrote:
> 
> Here is the use case:
> 
> We have a content-optimization (compression) proxy sitting between the browser and origin server. Among other things, the proxy can compress videos. When the browser starts playing a video, it makes an initial HTTP request to fetch (part of) the video, then builds an in-memory representation of the video and uses additional HTTP range requests as needed to fetch the rest of the video. For example, range requests are used to implement seeking.
> 
> The challenge is that we now have multiple representations of every video: the original representation (from the origin server) and one or more compressed representations served by the proxy. When the browser makes an initial request for a video, it gets one of these representations. When it makes a subsequent range request, we want to ensure that it receives the *same* representation that it received on the initial request. Otherwise the browser cannot combine the second response with the first response and video playback will fail.
> 
> An additional challenge is that the browser and proxy both have a cache. In theory, we control the entire connection and could add custom code to the browser, proxy, and caches to implement any protocol that we invent. In practice, both caches are intended to be HTTP-compliant caches and we'd rather not add custom hacks for use cases like this if we can avoid it.
> 
> The browser needs to label each range request with the ETag it expects to receive. If-Match originally seemed like the perfect solution: The browser adds `If-Match: ETag` to every range request. If a cache has a copy of the video with a *different* ETag, the cache forwards the request to the next server in the chain rather than returning its cached copy (as would happen if we used If-Range instead of If-Match). Similarly, the proxy knows if the browser is requesting a compressed video or the original video, so it can respond accordingly. However, as discussed previously in this thread, If-Match doesn't work like this.
> 
> Note that I agree it doesn't make sense for a cache to return 412 and we don't need that behavior. The semantics I'm looking for is: "Send me this representation if you have it, otherwise forward to the next server. A 4xx means that this representation is not current in the origin or in any intermediate cache or proxy."
> 
> Hope that makes sense.

You have several choices:

 1) implement this using transfer encodings because they don't change range offsets;
     presumably, these would be added/removed by the protocol handlers before
     the caches ever see them.

 2) use If-Range and configure your proxy to forward the request when no match;
     yes, that's legitimate HTTP (a server is free to ignore partial requests and a proxy
     can forward any request it likes).

 3) use If-Match and deal with the extra round-trip after a 412.

I don't see any reason here to change the handling of If-Match.  Partial requests are
why we have If-Range.

....Roy