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

From: Tom Bergan <[email-masked]>
Date: Wed, 1 Mar 2017 17:49:59 -0800

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.

On Mon, Feb 27, 2017 at 5:03 PM, Roy T. Fielding <[email-masked]> wrote:

> > On Feb 26, 2017, at 3:49 PM, Mark Nottingham <[email-masked]> wrote:
> >
> > I think the best way to characterise the situation currently is that
> HTTP doesn't define any requirements for If-Match on non-origin servers;
> the only requirements in 7232 Section 3.1 apply to origin servers.
> >
> > AFAIK current intermediaries ignore If-Match, so if you wanted to define
> some guidelines here, they'd need to be completely optional. E.g., "An
> intermediary MAY process If-Match based upon the contents of its cache,
> replying with 4xx when..." (note that that's just rapid hand-waving, not
> suggested spec text).
> >
> > If we did that, we'd have a header whose handling by origin servers was
> mandatory for some methods, and handling by intermediary servers was
> optional for other methods. Not sure how much that would confuse people,
> but properly spec'd, it'd probably be OK.
> >
> > We'd also have to have a discussion about whether 412 was the right
> status code.
> >
> > Roy, any thoughts?
> >
> > Tom, can you say any more about your use case?
>
> My thoughts would probably depend on the use case.
> Note that the HTTP spec is only defining rules for communication
> between independent components.  Although the internal architecture of
> a user agent might include something like an HTTP cache, HTTP's rules
> do not limit communication between the UA and its own internal cache.
> As far as HTTP is concerned, they are both part of the user agent.
>
> Thus, the sentence in 3.1:
>
>    It can also be used with safe
>    methods to abort a request if the selected representation does not
>    match one already stored (or partially stored) from a prior request.
>
> is referring to one already stored on the user agent from a prior
> request by that user agent.
>
> Originally, If-Match was defined to be answerable by intermediaries
> for GET/HEAD requests.  However, 412 was considered by the WG to be an
> undesirable response in those cases, so If-Range was created to
> replace that function. My guess is that's the use case here. OTOH,
> a 412 might be preferred for safe methods other than GET and HEAD.
>
> AFAICR, limiting If-Match requirements to origin servers in RFC7232
> was due to lack of implementation by clients (aside from the unsafe
> methods) and a desire for semantic consistency for the field.
>
> For unsafe methods, the client's field value is referring to the
> current selected representation on the origin server, which is something
> that can only be tested by the origin server. Having a special-case for
> safe methods meant that both the meaning of the field changed per
> method and the need to implement it changed per method, which is quite
> a bit of complexity for a feature that nobody ever used.
>
> BTW, Apache httpd implements If-Match in the default resource handler
> and anywhere that calls ap_meets_conditions().  That will result in a
> 412 response to an otherwise successful request if the etag given
> doesn't match the selected representation, regardless of the method.
> [I haven't tested it to see if that gets called by default when the
> server is installed as an intermediary.]
>
> Cheers,
>
> ....Roy
>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 3 Mar 2017 14:30:37 -0800

On Mar 1, 2017, at 5:49 PM, Tom Bergan <[email-masked]> 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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 4 Mar 2017 09:58:24 +1100

> On 4 Mar 2017, at 9:30 am, Roy T. Fielding <[email-masked]> wrote:
> 

Ew.

>     can forward any request it likes).

Nod.

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

Why doesn't the logic in #2 apply here as well? Intermediary servers aren't required to 412.

--
Mark Nottingham   https://www.mnot.net/

---

From: Tom Bergan <[email-masked]>
Date: Fri, 3 Mar 2017 15:24:50 -0800

On Fri, Mar 3, 2017 at 2:58 PM, Mark Nottingham <[email-masked]> wrote:

> >> The challenge is that we now have multiple representations of every
> video: the original representation (from the origin server) and one or more
> >> 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

Can you expand what you mean by this? I'm not sure I followed.

In case I wasn't clear, the proxy actually produces a completely different
transcode of the original video, possibly in a different container format
or codec. The "compressed" video is actually a completely different file
than the original video; this is not just compression via Content-Encoding.

> >     can forward any request it likes).

This doesn't help with the caches, which return 200 when there is no match
on the If-Range etag rather than forwarding the request. If we didn't have
any HTTP caches in the middle, we would have already done this :)

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 3 Mar 2017 16:11:19 -0800

On Mar 3, 2017, at 3:24 PM, Tom Bergan <[email-masked]> wrote:
> On Fri, Mar 3, 2017 at 2:58 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> > On 4 Mar 2017, at 9:30 am, Roy T. Fielding <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > On Mar 1, 2017, at 5:49 PM, Tom Bergan <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Here is the use case:
> >>
> In case I wasn't clear, the proxy actually produces a completely different transcode of the original video, possibly in a different container format or codec. The "compressed" video is actually a completely different file than the original video; this is not just compression via Content-Encoding.

If the encoding is reversible (lossless), transfer encoding is a better idea.  Of course,
this has zero chance of being implemented already -- it would be custom code.

> This doesn't help with the caches, which return 200 when there is no match on the If-Range etag rather than forwarding the request. If we didn't have any HTTP caches in the middle, we would have already done this :)

You control those HTTP caches, right? Change that behavior.  We are talking about a trivial
configuration change (or a one-line source code change), as opposed to a change to HTTP
semantics which, even if we agreed to it, wouldn't be deployed for another five years.

OTOH, you can just do the sensible thing and use a different URL for the compressed stream.
Then the proxy can redirect initial (normal) requests to the compressed stream when it already
has the beginning of that stream in cache.

> Why doesn't the logic in #2 apply here as well? Intermediary servers aren't required to 412.

They are required to either not implement it or not perform the method.  Either way, the
response isn't going to be what you want (a 2xx status) because that would change the
semantics of the field. Your use case fits If-Range's purpose, not that of If-Match.
To be clear regarding the subject, the RFC doesn't say caches and intermediaries always
ignore If-Match; it says they may.  Deployed practice will just as often respond with a 412
when an unmatched etag is received in If-Match.

....Roy

---

From: Tom Bergan <[email-masked]>
Date: Fri, 3 Mar 2017 16:24:10 -0800

> semantics which, even if we agreed to it, wouldn't be deployed for another

I think you're under-stating the maintenance complexity of adding
non-standard behavior to caches that are generally expected to have
standard HTTP behavior. But, I understand the reluctance to change HTTP
semantics, so we'll look into a non-standard or custom solution.

OTOH, you can just do the sensible thing and use a different URL for the
> compressed stream.

This doesn't solve the problem completely either. The proxy still needs to
distinguish initial requests (where it can return a redirect) from
subsequent requests (where it cannot). Obviously this is easy to signal
with any custom protocol, but I was trying to figure out if there's a
purely standards-compliant solution to this problem. It sounds like no, so
I'll do something custom.