Resent-Date: Fri, 03 Mar 2017 22:31:17 +0000
Resent-Message-Id: <E1cjvjJ-00005k-22@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CA+3+x5HZJsJ+903UKx+2O0b2dtc7o48Ks8CGrGfs=E_dXyWx-g@mail.gmail.com>
Date: Fri, 3 Mar 2017 14:30:37 -0800
Cc: Mark Nottingham <mnot@mnot.net>,
 Alex Rousskov <rousskov@measurement-factory.com>,
 HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <629EE31B-7235-4EFB-9C4C-CA4010165B2F@gbiv.com>
References: <CA+3+x5FgdfAQ4Nos9VTGe35RiH8Z+3zZiUGH_bKXHz+VO+UAbQ@mail.gmail.com>
 <aaedcb18-2a19-9b77-95d9-0559e21407c2@measurement-factory.com>
 <CA+3+x5E_HPycm4axSLtO0jGmjDBS3=kVfhaJzKR+7n7S_yMgkg@mail.gmail.com>
 <DEF639B3-6A6D-4030-93D0-B7473D2A14F6@mnot.net>
 <9DA41CBA-673C-416B-A9CF-AD9A108C2440@gbiv.com>
 <CA+3+x5HZJsJ+903UKx+2O0b2dtc7o48Ks8CGrGfs=E_dXyWx-g@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com;
 helo=homiemail-a40.g.dreamhost.com
Subject: Re: Why should caches and intermediaries ignore If-Match?
Archived-At: <http://www.w3.org/mid/629EE31B-7235-4EFB-9C4C-CA4010165B2F@gbiv.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

On Mar 1, 2017, at 5:49 PM, Tom Bergan <tombergan@chromium.org> wrote:
>=20
> Here is the use case:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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."
>=20
> 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