what constitutes an "invalid" content-length

"Adrien de Croy" <adrien@qbik.com> Tue, 12 July 2016 14:28 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 4C75B12E0B0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jul 2016 07:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.207
X-Spam-Level:
X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 Kj0kU2WzDx1U for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jul 2016 07:28:05 -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 2A59012DE74 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Jul 2016 06:36:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bMxnJ-0002Ny-LZ for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Jul 2016 13:32:13 +0000
Resent-Date: Tue, 12 Jul 2016 13:32:13 +0000
Resent-Message-Id: <E1bMxnJ-0002Ny-LZ@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 1bMxnF-0002Mn-8C for ietf-http-wg@listhub.w3.org; Tue, 12 Jul 2016 13:32:09 +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 1bMxn8-0007ZI-Fv for ietf-http-wg@w3.org; Tue, 12 Jul 2016 13:32:08 +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 5838)) with SMTP id <0000774470@smtp.qbik.com>; Wed, 13 Jul 2016 01:31:32 +1200
From: Adrien de Croy <adrien@qbik.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Date: Tue, 12 Jul 2016 13:31:32 +0000
Message-Id: <em19b7fba4-42bf-40e8-83a9-132dfdc92698@bodybag>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB2BDF4A5F-05DE-4E40-B511-FC5CE6827E72"
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.3
X-W3C-Hub-Spam-Report: AWL=-0.086, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bMxn8-0007ZI-Fv 2b389bcdd4480c3ee10546bd94471857
X-Original-To: ietf-http-wg@w3.org
Subject: what constitutes an "invalid" content-length
Archived-At: <http://www.w3.org/mid/em19b7fba4-42bf-40e8-83a9-132dfdc92698@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31926
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 all

just dealing with a site that sends more payload data than is indicated 
in the Content-Length header.

If the browser connects directly, the page loads fine, if via the proxy, 
the proxy is truncating the length to that advertised and the client 
isn't displaying a page (of course this is the .css file).

RFC7230 sections 3.3.2 (Content-Length), 3.3.3 (Message body length), 
and 3.3.4 (Handling incomplete messages) only contemplate issues around 
Content-Length specifying more bytes than are received, not fewer.

I guess one could argue that a wrong C-L value is "invalid", but it's 
not clear that invalid in this context simply means it doesn't parse, or 
is otherwise non-compliant with the ABNF.

So, it's not clear what the browser and/or proxy response should be.  If 
we deem a wrong value to be "invalid" (s3.3.3 para 4), a client is 
supposed to discard the response.  This isn't happening.

For the proxy, it only sees that the content length is wrong once it 
receives too many bytes.  By this stage, the horse has bolted so it 
cannot really comply either.

I would expect it's in everyone's best interest if sites that have 
broken framing are forced to be fixed.  This won't happen if browsers 
"just work" for the site.

Is there a special behaviour we should agree on for such cases?

Regards

Adrien de Croy