Re: 304 on Non-Conditional Request?

"Adrien de Croy" <adrien@qbik.com> Tue, 16 August 2016 02: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 4636812D12D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Aug 2016 19:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Level:
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-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 akHr7jIZDWgd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Aug 2016 19:08:27 -0700 (PDT)
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 D2C3E12D19E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 15 Aug 2016 19:08:27 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bZTjR-0006ie-AE for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Aug 2016 02:03:57 +0000
Resent-Date: Tue, 16 Aug 2016 02:03:57 +0000
Resent-Message-Id: <E1bZTjR-0006ie-AE@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <adrien@qbik.com>) id 1bZTjM-0006gt-23 for ietf-http-wg@listhub.w3.org; Tue, 16 Aug 2016 02:03:52 +0000
Received: from smtp.qbik.com ([122.56.26.1]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <adrien@qbik.com>) id 1bZTjG-0003wZ-UB for ietf-http-wg@w3.org; Tue, 16 Aug 2016 02:03:48 +0000
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.0 (Build 5853)) with SMTP id <0000803728@smtp.qbik.com>; Tue, 16 Aug 2016 14:03:15 +1200
From: Adrien de Croy <adrien@qbik.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Mark Nottingham <mnot@mnot.net>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Date: Tue, 16 Aug 2016 02:03:15 +0000
Message-Id: <em0f29ead4-bd52-46f1-8b47-9a207d395052@bodybag>
In-Reply-To: <20160815082308.GB14695@1wt.eu>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=122.56.26.1; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-0.514, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bZTjG-0003wZ-UB 176cf06c7e887744b4dee7521b552843
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 304 on Non-Conditional Request?
Archived-At: <http://www.w3.org/mid/em0f29ead4-bd52-46f1-8b47-9a207d395052@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32272
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>

Actually there's a hole in the spec maybe.

if you get a 304 response to a request that had more than 1 Etag, and 
the Etag in the response doesn't match any of the Etags from the 
request, then there's no way to choose which representation is being 
indicated by the 304.

Is this just a broken server?  We see 304s come back all the time with 
new Etags, and I'm pretty sure I've seen comments about just treating it 
as metadata and updating the stored Etag, but fundamentally

if 304 means no change, and
different Etag means it changed,

then which is it?  And this only "works" if there's only 1 Etag.

Adrien

------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Mark Nottingham" <mnot@mnot.net>; "Mike Bishop" 
<Michael.Bishop@microsoft.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 15/08/2016 8:23:08 PM
Subject: Re: 304 on Non-Conditional Request?

>Hi Adrien,
>
>On Fri, Aug 12, 2016 at 01:32:03AM +0000, Adrien de Croy wrote:
>>  if the request was non-conditional, that would also happen if you 
>>didn't
>>  have any version already.  Client basically needs to retry.
>>
>>  FWIW we see this happen quite a bit with proxies encountering broken
>>  servers.
>>
>>  E.g.
>>
>>  1. client makes non-conditional request to proxy.
>>  2. Proxy has a stale version
>>  3. Proxy adds If-None-Match and stored ETag
>>  4. Server responds with 304 with different ETag (yes, there are 
>>several
>>  high-profile servers that frequently do this)
>>  5. Exasperated proxy forwards 304 to the client, which then has to 
>>retry,
>>  hopefully the proxy removed the invalidated (by ETag) cache entry in 
>>the
>>  meantime so it works the second time.
>
>A long time ago (~15 years) I've been experiencing a different case 
>where
>a caching proxy would ignore the if-none-match field, pass the request 
>to
>the server, which responds 304, which is forwarded to the client and 
>cached
>by the proxy. The next client requesting the same object to the proxy 
>would
>be delivered the 304 from the cache.
>
>Willy