Re: WGLC: p4, 304 Not Modified

Mark Nottingham <mnot@mnot.net> Mon, 29 April 2013 12:32 UTC

Return-Path: <ietf-http-wg-request@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 DB3C821F9D86 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 05:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.819
X-Spam-Level:
X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y19QSN+4DSIf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 05:32:29 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3426A21F9D83 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 05:32:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWnFX-0007Mw-52 for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 12:32:07 +0000
Resent-Date: Mon, 29 Apr 2013 12:32:07 +0000
Resent-Message-Id: <E1UWnFX-0007Mw-52@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWnFS-0007Li-1W for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 12:32:02 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWnFQ-0004tH-Tm for ietf-http-wg@w3.org; Mon, 29 Apr 2013 12:32:01 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 130A350A84; Mon, 29 Apr 2013 08:31:38 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <517E6504.5050709@andrew.cmu.edu>
Date: Mon, 29 Apr 2013 22:31:35 +1000
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D6409E-9EF5-462C-8BCD-4E16630C5B8F@mnot.net>
References: <516D5C36.4040003@andrew.cmu.edu> <517E6504.5050709@andrew.cmu.edu>
To: Ken Murchison <murch@andrew.cmu.edu>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.440, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWnFQ-0004tH-Tm 157997722873369e7324f2c67c3fda26
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC: p4, 304 Not Modified
Archived-At: <http://www.w3.org/mid/24D6409E-9EF5-462C-8BCD-4E16630C5B8F@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17656
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>

Hi Ken,

I re-opened this issue as a result:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/345

We didn't add Last-Modified (or rather, we added it and then took it out) because doing so would make some existant implementations non-conformant, and there isn't a clear win in interop or security by doing so.

Also, ETag is used by caches to help differentiate the selected response, when multiple etags are sent in If-None-Match.

That said, it's a good question as to why some things are required to be returned when they haven't changed, as this *does* represent a change from 2616; hence, the reopened issue.

Cheers,


On 29/04/2013, at 10:18 PM, Ken Murchison <murch@andrew.cmu.edu> wrote:

> Any thoughts on this?
> 
> 
> Ken Murchison wrote:
>> Hi All,
>> 
>> In re-reading the latest section 4.1, I'm wondering why ETag was singled out as being a MUST generate, while Last-Modified isn't.  If the server is capable of generating both, shouldn't it return both, as it SHOULD for 200 responses (per section 2.4)?  What if the client only supports Last-Modified and not ETag (e.g. used If-Modified-Since in its request)?
>> 
>> That being said, if the representation hasn't been modified then presumably none of the validators changed.  What's the point in returning any of them?  Shouldn't it be all or nothing?  Just trying to wrap my head around the logic behind singling out ETag over Last-Modified for 304.
>> 
> -- 
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
> 
> 

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