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

"Roy T. Fielding" <fielding@gbiv.com> Tue, 28 February 2017 01:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0995129469 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Feb 2017 17:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.022
X-Spam-Level:
X-Spam-Status: No, score=-7.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZLHLZ86uXqo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Feb 2017 17:08:29 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1301293FD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 27 Feb 2017 17:08:28 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ciWE9-0006Nt-GC for ietf-http-wg-dist@listhub.w3.org; Tue, 28 Feb 2017 01:05:17 +0000
Resent-Date: Tue, 28 Feb 2017 01:05:17 +0000
Resent-Message-Id: <E1ciWE9-0006Nt-GC@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1ciWE0-0005BQ-0H for ietf-http-wg@listhub.w3.org; Tue, 28 Feb 2017 01:05:08 +0000
Received: from hapkido.dreamhost.com ([66.33.216.122]) by titan.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <fielding@gbiv.com>) id 1ciWDt-0002T9-4g for ietf-http-wg@w3.org; Tue, 28 Feb 2017 01:05:02 +0000
Received: from homiemail-a91.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by hapkido.dreamhost.com (Postfix) with ESMTP id 01ABC9019B for <ietf-http-wg@w3.org>; Mon, 27 Feb 2017 17:04:18 -0800 (PST)
Received: from homiemail-a91.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTP id C89B02E24; Mon, 27 Feb 2017 17:03:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=Vv6y6sZYU0c7xBJaCZX/Glx8c9Y=; b=lTgpE+xvIBHfDmEC2L/EVH7jIJXU 76Jh8dIJPaB0fceDu8nPPo6HY53JCepWp91qiUeNsF1pkqvnfy7indlXDzBdHDBi w92Ac3bxrlaYqKlbiahLO17nJRy32doj43wJXqXxI6xWYsX+SOVglcWFJUmDFUmd yrsxWLJDcT5D6ug=
Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTPSA id ADF032E21; Mon, 27 Feb 2017 17:03:34 -0800 (PST)
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: <DEF639B3-6A6D-4030-93D0-B7473D2A14F6@mnot.net>
Date: Mon, 27 Feb 2017 17:03:34 -0800
Cc: Tom Bergan <tombergan@chromium.org>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DA41CBA-673C-416B-A9CF-AD9A108C2440@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>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=66.33.216.122; envelope-from=fielding@gbiv.com; helo=hapkido.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=-0.079, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_PSBL=2.7, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ciWDt-0002T9-4g 8492115f5972b98355f3a31e35b25df2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Why should caches and intermediaries ignore If-Match?
Archived-At: <http://www.w3.org/mid/9DA41CBA-673C-416B-A9CF-AD9A108C2440@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33624
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Feb 26, 2017, at 3:49 PM, Mark Nottingham <mnot@mnot.net> 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