Re: WGLC p1: MUST fix Content-Length?

Willy Tarreau <w@1wt.eu> Wed, 01 May 2013 07:23 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 914E121F86BB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 00:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Level:
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 OgmjeaqRAosc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 00:23:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1F21F869A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 May 2013 00:23:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UXRNI-0002Ng-GE for ietf-http-wg-dist@listhub.w3.org; Wed, 01 May 2013 07:22:48 +0000
Resent-Date: Wed, 01 May 2013 07:22:48 +0000
Resent-Message-Id: <E1UXRNI-0002Ng-GE@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UXRN9-0002LZ-O0 for ietf-http-wg@listhub.w3.org; Wed, 01 May 2013 07:22:39 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UXRN8-0006yL-Th for ietf-http-wg@w3.org; Wed, 01 May 2013 07:22:39 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r417MBq7028928; Wed, 1 May 2013 09:22:11 +0200
Date: Wed, 01 May 2013 09:22:11 +0200
From: Willy Tarreau <w@1wt.eu>
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: IETF HTTP WG <ietf-http-wg@w3.org>
Message-ID: <20130501072211.GH27137@1wt.eu>
References: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net> <5180ADD8.8060307@measurement-factory.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5180ADD8.8060307@measurement-factory.com>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-0.812, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.57, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UXRN8-0006yL-Th e14bd2e49f9799ec37ec7a3de1684945
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC p1: MUST fix Content-Length?
Archived-At: <http://www.w3.org/mid/20130501072211.GH27137@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17750
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 Tue, Apr 30, 2013 at 11:53:28PM -0600, Alex Rousskov wrote:
> Hello,
> 
>     When talking about a Content-Length header field with multiple
> identical values, Part 1 Section 3.3.2 of HTTPbis says:
> 
> > the recipient MUST either reject the message as invalid or
> > replace the duplicated field-values with a single valid
> > Content-Length field containing that decimal value prior to
> > determining the message body length.
> 
> It is not clear whether "recipient MUST replace" (a requirement on the
> recipient) also implies that "a sender MUST replace [...] when
> forwarding the message" (a requirement on the sender). This issue has
> been raised on 2011/11/28, but the discussion diverged, and I could not
> tell whether there was a consensus on what the correct interpretation is.
> 
> Please decide whether a proxy MUST "fix" such Content-Length headers
> when forwarding the message and adjust the above text to clarify one way
> or another.

That's what the discussion converged to. I even modified haproxy in order
to do so. The idea is simple : if you receive a message with multiple
content lengths, either you can't deal with them and must reject the
message, or you can deal with them and then you know how to fix the
message before interpreting it or forwarding it, so you must do so.

Do you think the text needs to be adjusted ?

It can be seen as a constraint to fix a message before forwarding it,
but in fact it's a relaxation of a case where you were supposed to
reject the message.

Willy