Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

Alex Rousskov <rousskov@measurement-factory.com> Wed, 15 February 2017 01:19 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 6EB5B129473 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Feb 2017 17:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 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] 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 VKZDLIPAbSha for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Feb 2017 17:19:46 -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 41FFA129460 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 Feb 2017 17:19:46 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cdoCk-0001g5-K4 for ietf-http-wg-dist@listhub.w3.org; Wed, 15 Feb 2017 01:16:22 +0000
Resent-Date: Wed, 15 Feb 2017 01:16:22 +0000
Resent-Message-Id: <E1cdoCk-0001g5-K4@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 1cdoCg-0001ex-3o for ietf-http-wg@listhub.w3.org; Wed, 15 Feb 2017 01:16:18 +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 1cdoCZ-00045e-VG for ietf-http-wg@w3.org; Wed, 15 Feb 2017 01:16:12 +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 6FD6CE037; Wed, 15 Feb 2017 01:15:50 +0000 (UTC)
To: Adrien de Croy <adrien@qbik.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
References: <emdcb96fc0-0d2f-436c-9f1f-05beffe7593e@bodybag> <e01c4945-1116-d258-7004-ea917843bf3d@ninenines.eu> <ema747b801-6dcc-4b2d-ac95-9a027e10c0b4@bodybag> <7874c62b-c6a0-5d84-8115-20016b45118a@measurement-factory.com> <em541e3407-4e99-468e-a1e7-85a7bf074bdd@bodybag> <874938e6-2153-e02a-ab0e-814f468c58f8@measurement-factory.com> <em95b13204-3a33-4bd5-81d2-791e809b9cd2@bodybag> <0f12628c-ab62-22c2-2cf3-e4b456072597@measurement-factory.com> <emdcdebbb8-1ff5-4139-b8f2-409fe94eb6e8@bodybag>
From: Alex Rousskov <rousskov@measurement-factory.com>
Message-ID: <eb6dc6f5-1a90-df46-71b1-7d6373f6eff4@measurement-factory.com>
Date: Tue, 14 Feb 2017 18:15:49 -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: <emdcdebbb8-1ff5-4139-b8f2-409fe94eb6e8@bodybag>
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.614, 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 1cdoCZ-00045e-VG 06ee7039eac29eada5bbc00e1d0cbc0a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
Archived-At: <http://www.w3.org/mid/eb6dc6f5-1a90-df46-71b1-7d6373f6eff4@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33515
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/14/2017 05:42 PM, Adrien de Croy wrote:
>>>  The only true size of a body is what you obtain by counting its bytes.

>> I disagree. The only true size of a body is the Content-Length value (in
>> relevant contexts).

> What about for a sender piecing a message together.  Where does
> Content-Length come from?
> 
> The content existed before you derived or obtained its length.

The content may have existed, of course, but the HTTP message (and,
hence, HTTP message body) did not.

When the agent creates an HTTP message with a Content-Length header (no
T-E, etc.), that agent determines the HTTP message body size. Whether
the agent first computes the C-L header value or imports the body is an
irrelevant implementation detail from the _protocol_ point of view. On
the protocol/conceptual level, the header value and the body size are
the same thing. We could add qualifiers like expected or anticipated
message body size but they actually make the text less accurate IMHO.

Consider an agent that reads body content from a 100-byte file, counts
each byte read, but forgets to read the last byte (bug!) and then sets
the Content-Length header value to 42 (another bug!). From the HTTP
point of view, the message body is going to be 42 bytes long even though
that body does not accurately represent the content the agent read from
the disk or the content it ought to be actually sending.

And the above example will still stand if I replace 100 with 10!

Alex.