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

Alex Rousskov <rousskov@measurement-factory.com> Fri, 17 February 2017 01:25 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 7CC2812973A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Feb 2017 17:25:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dTASMrLjoIZB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Feb 2017 17:25:07 -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 D5D751289B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Feb 2017 17:25:07 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ceXFA-0008WS-RE for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Feb 2017 01:21:52 +0000
Resent-Date: Fri, 17 Feb 2017 01:21:52 +0000
Resent-Message-Id: <E1ceXFA-0008WS-RE@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 <rousskov@measurement-factory.com>) id 1ceXF5-0008T4-2V for ietf-http-wg@listhub.w3.org; Fri, 17 Feb 2017 01:21:47 +0000
Received: from mail.measurement-factory.com ([104.237.131.42]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <rousskov@measurement-factory.com>) id 1ceXEy-0005uR-Uh for ietf-http-wg@w3.org; Fri, 17 Feb 2017 01:21:41 +0000
Received: from [65.102.233.169] (unknown [65.102.233.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id AF3A0E037; Fri, 17 Feb 2017 01:21:18 +0000 (UTC)
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <CA+3+x5FgdfAQ4Nos9VTGe35RiH8Z+3zZiUGH_bKXHz+VO+UAbQ@mail.gmail.com>
From: Alex Rousskov <rousskov@measurement-factory.com>
Cc: Tom Bergan <tombergan@chromium.org>
Message-ID: <aaedcb18-2a19-9b77-95d9-0559e21407c2@measurement-factory.com>
Date: Thu, 16 Feb 2017 18:21:18 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CA+3+x5FgdfAQ4Nos9VTGe35RiH8Z+3zZiUGH_bKXHz+VO+UAbQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=104.237.131.42; envelope-from=rousskov@measurement-factory.com; helo=mail.measurement-factory.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-0.571, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ceXEy-0005uR-Uh 183d89789cd8f81742c1d436b506fe49
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/aaedcb18-2a19-9b77-95d9-0559e21407c2@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33562
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 02/15/2017 04:43 PM, Tom Bergan wrote:

> RFC 7232 Section 3.1 says:
> 
>> The If-Match header field can be ignored by caches and intermediaries
>> because it is not applicable to a stored response.
> 
> RFC 7234 Section 4.3.2 says the same thing:
> 
>> The If-Match ... conditional header fields are not applicable to a cache.
> 
> Why?


When rewriting RFC 2616, HTTPbis authors concluded that "caches don't
have enough information to process methods like If-Match" and decided to
limit If-Match and If-Unmodified-Since effects to origin servers:

    https://trac.ietf.org/trac/httpbis/ticket/498
    https://trac.ietf.org/trac/httpbis/ticket/479
    https://trac.ietf.org/trac/httpbis/changeset/2408

I bet the authors were thinking about classic use cases that deal with
uncachable resources created and/or updated on the origin server via
POST/PUT/DELETE methods and missed some more esoteric use cases.

N.B. "can be ignored" is not exactly "MUST ignore" so there is some
wiggle room for cache optimization here (e.g., mismatching cached
resources do not have to be DELETEd from a proxy cache, I guess).


> Suppose the client sends a GET request with If-Match: "A". This request
> is first sent to an HTTP cache. Suppose the requested resource is
> cached, and suppose the cache ignores the If-Match header as suggested
> above. If the cache has version "B" cached, not version "A", the cache
> will return a 2xx with ETag: "B". 

Yes, If-Match in HTTPbis is not designed to work [well] with GET methods
that result in cachable responses.


> This behavior is surprising and seems
> to contradict the following statement from RFC 7232 Section 3.1:

>> [If-Match] 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.

I suspect this text now refers to representations stored on the origin
server [as the result of prior conditional requests], not
representations cached by a proxy. Again, the former is probably the
only intentionally supported use case as far as HTTPbis is concerned.


> I am trying to use If-Match for exactly this reason.

Then you have two options:

A) Claim that s/server/origin/g change was wrong and fix HTTPbis RFCs.
B) Make sure your responses are not cachable.

Given the widespread changes and serious incompatibility with RFC 2616
that an HTTPbis fix to satisfy your use case would require, I cannot
recommend (A) unless HTTPbis authors explicitly encourage you to propose
a fix.


> I understand why a cache would not generate 412s. The cache is not
> authoritative for the resource and 412 implies authority. But, it seems
> like the cache should never respond with an ETag that is disallowed by
> If-Match, and if the cache does not have an allowed ETag, then the
> request should be forwarded to the origin. Does that sound right?

It sounds reasonable to me but it would violate the original RFC 2616
text and go against the letter (but perhaps not the intent) of the new
HTTPbis rules.


HTH,

Alex.