WGLC p1: Delimiting messages with multipart/byteranges

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Mon, 29 April 2013 18:48 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5A91621F9A6A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 11:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oDR4zMRPDFkM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 11:48:29 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org []) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9B21F9AE5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 11:48:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWt7R-0001hD-Ek for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 18:48:09 +0000
Resent-Date: Mon, 29 Apr 2013 18:48:09 +0000
Resent-Message-Id: <E1UWt7R-0001hD-Ek@frink.w3.org>
Received: from lisa.w3.org ([]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ben@niven-jenkins.co.uk>) id 1UWt7G-0001e7-P4 for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 18:47:58 +0000
Received: from mailex.mailcore.me ([]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <ben@niven-jenkins.co.uk>) id 1UWt7F-0006U0-WD for ietf-http-wg@w3.org; Mon, 29 Apr 2013 18:47:58 +0000
Received: from [] (helo=xxx.corp.velocix.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1UWt6u-0000Mn-PT for ietf-http-wg@w3.org; Mon, 29 Apr 2013 19:47:36 +0100
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Apr 2013 19:47:35 +0100
Message-Id: <C40C9D66-FEEE-4B10-A0E9-1689B56543AA@niven-jenkins.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Received-SPF: none client-ip=; envelope-from=ben@niven-jenkins.co.uk; helo=mailex.mailcore.me
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.500, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1UWt7F-0006U0-WD 4c416904a156a5af29e372e0598e9272
X-Original-To: ietf-http-wg@w3.org
Subject: WGLC p1: Delimiting messages with multipart/byteranges
Archived-At: <http://www.w3.org/mid/C40C9D66-FEEE-4B10-A0E9-1689B56543AA@niven-jenkins.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17669
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>


The p1 HTTPbis draft has removed using multipart/byteranges as a message delimiter in 206 responses (which was previously allowed by RFC2616).

I see this was originally tracked as Ticket #90 and the outcome was to deprecate such behaviour in all cases including in 206 responses with Content-Type: multipart/byteranges (which is the only case I care about).

This decision makes previously conforming implementations (such as our reverse proxy implementation) now non-conformant and the alternatives of: (A) close connection after every multipart/byteranges response or (B) pre-calculate message body length (including header/boundary bytes for each byterange) in advance, are inconvenient.

Would it be possible to re-allow use of multipart/byteranges as a message delimiter in the case where it is a 206 response AND there is no Transfer-Encoding AND there is no Content-Length so that implementations such as ours are classed as conformant again?

Even if it is decided to stick with the current state of affairs in -22 where generating 206 responses that use multipart/byteranges as a delimiter is forbidden, the specification should still specify how to parse such responses in a backwardly compatible manner as generating such responses was previously allowed & used and so User Agents should still expect to receive them from pre-httpbis implementations.