Re: Last-Modified header in 304 and 206 responses

Amos Jeffries <squid3@treenet.co.nz> Fri, 13 April 2012 06:58 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 4A2F121F865E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Apr 2012 23:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.4
X-Spam-Level:
X-Spam-Status: No, score=-10.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 qrW7IcuqgspM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Apr 2012 23:58:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A472621F865F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 12 Apr 2012 23:58:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SIaQF-0005Lf-Th for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Apr 2012 06:55:55 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <squid3@treenet.co.nz>) id 1SIaPy-0005JR-3B for ietf-http-wg@listhub.w3.org; Fri, 13 Apr 2012 06:55:38 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1SIaPr-0006yZ-I9 for ietf-http-wg@w3.org; Fri, 13 Apr 2012 06:55:36 +0000
Received: from [10.1.1.14] (unknown [119.224.40.49]) by treenet.co.nz (Postfix) with ESMTP id 6B288E6D7E for <ietf-http-wg@w3.org>; Fri, 13 Apr 2012 18:55:09 +1200 (NZST)
Message-ID: <4F87CDCA.1030503@treenet.co.nz>
Date: Fri, 13 Apr 2012 18:55:06 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CACuKZqE5KDyk1soOfb_BrYgWF-gmQZzsu0dg2iV6KW2VtoW5fw@mail.gmail.com>
In-Reply-To: <CACuKZqE5KDyk1soOfb_BrYgWF-gmQZzsu0dg2iV6KW2VtoW5fw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SIaPr-0006yZ-I9 36f7d797327041004564e9f6f51ddebc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Last-Modified header in 304 and 206 responses
Archived-At: <http://www.w3.org/mid/4F87CDCA.1030503@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13434
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>
Resent-Message-Id: <E1SIaQF-0005Lf-Th@frink.w3.org>
Resent-Date: Fri, 13 Apr 2012 06:55:55 +0000

On 7/04/2012 11:28 a.m., Zhong Yu wrote:
> In RFC2616, Last-Modified header was not allowed in 304 and 206(to an
> If-Range request)
>
>    http://tools.ietf.org/html/rfc2616#section-10.3.5
>    http://tools.ietf.org/html/rfc2616#section-10.2.7
>
> In draft 19, Last-Modified is allowed/required in 206/If-Range, but
> still forbidden in 304
>
>    http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-19#section-4.1
>    http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#section-3.1
>
> Any reason for the asymmetry?
>
> Furthermore, why must we exclude other entity headers in 304 and
> 206/If-Range? There are only 3 of them: Content-Encoding,
> Content-Language, Content-Type. They can't have any meaningful impact
> on performance if they are included in the response. Do they really
> deserve a "SHOULD NOT be included"?

Turning that on its head. What use case needs including them?

Two reasons for not including them:

1) including headers on 304 means they *have* changed from the request 
being tested.

For example;
   when testing/validating a text/html English language object modified 
2012-04-10 12:00am

Would you expect the 304 response assertion that "yes this binary/gif 
object with Greek text has not changed since 2012-04-11 12:00am" to 
*ever* be valid?

For the 304 response to be valid those headers MUST be fixed constant 
values with no possibility for corruption after the 200 response with 
entity.


2) those headers are specifically defined as being related to the entity 
attached to the response.

When sent on a 206 they indicate the 206 entity details. Not some 
previous 200 responses.

It is reasonable to expect a range request which asked for example bytes 
0-256 of a 4KB object without specifying which variant (gzip, identity, 
etc) forms of the object is held already. The 206 entity might therefore 
vary from one already held. This may not even matter for 
display/use/caching purposes, but it is *very* important to know whether 
merging of the ranges is or is not safe.

AYJ