Re: WGLC p1: Delimiting messages with multipart/byteranges

Zhong Yu <zhong.j.yu@gmail.com> Mon, 29 April 2013 22:46 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 8563421F9A9A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 15:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZNK7ixH1jLil for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 15:46:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3451C21F9A86 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 15:46:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWwpV-0004ic-Sc for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 22:45:53 +0000
Resent-Date: Mon, 29 Apr 2013 22:45:53 +0000
Resent-Message-Id: <E1UWwpV-0004ic-Sc@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UWwpJ-0004gU-Jh for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 22:45:41 +0000
Received: from mail-oa0-f45.google.com ([209.85.219.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1UWwpI-0000aE-Qq for ietf-http-wg@w3.org; Mon, 29 Apr 2013 22:45:41 +0000
Received: by mail-oa0-f45.google.com with SMTP id o17so6701841oag.18 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 15:45:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5nDe/LA2+R1fYitEZxwTQ0Jg+/4hArB3RlyIDi0DOY0=; b=N8noc1Smc63JgCSCZ0U6/M+s0Uhivqgpc1GjA51hiT1aXvH5fGKHKZstZ9ntNs8nyu /OGfXa3dd6gL6uCJE3Kclrd5Q6Ni3icdQeH1x8y5CyRJ845u9hBd8gQyO9gH7AK9vtaF iUXxFjnuKvOwKY4I59tsbHfKzKGGv0CQ5ADb90pRNTHMRpHW5ZBnba9CJIdsgj6LTvOT fRQ7PW6hS4AJuRvq1G64En2rQ5Un2FdlzlECMpbYRk1Lav5pbYOOmP0otA5cU5cJFpU3 fUPoIX36vMKkd7+TRWA6FTkhP4fPPD/4gesfv4yVlBXgwINe7YbJZj8R+zeBjT8IWmOA 921Q==
MIME-Version: 1.0
X-Received: by 10.182.27.40 with SMTP id q8mr24822287obg.100.1367275514898; Mon, 29 Apr 2013 15:45:14 -0700 (PDT)
Received: by 10.76.127.141 with HTTP; Mon, 29 Apr 2013 15:45:14 -0700 (PDT)
In-Reply-To: <C40C9D66-FEEE-4B10-A0E9-1689B56543AA@niven-jenkins.co.uk>
References: <C40C9D66-FEEE-4B10-A0E9-1689B56543AA@niven-jenkins.co.uk>
Date: Mon, 29 Apr 2013 17:45:14 -0500
Message-ID: <CACuKZqHyK9XEFK0Aa85tTzOWZTusyDp9SFC4Kd7S=k-CEhO7GA@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e0122976260327204db87a360
Received-SPF: pass client-ip=209.85.219.45; envelope-from=zhong.j.yu@gmail.com; helo=mail-oa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.707, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWwpI-0000aE-Qq 521ebf0b7171e2a63c9a19324f704664
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WGLC p1: Delimiting messages with multipart/byteranges
Archived-At: <http://www.w3.org/mid/CACuKZqHyK9XEFK0Aa85tTzOWZTusyDp9SFC4Kd7S=k-CEhO7GA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17691
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>

Question about trailing CRLF of a multipart body. RFC2046 defines

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]


RFC2616 forbids "epilogue" in http messages, but what about the trailing
CRLF? I know browsers do include a trailing CRLF when submitting
multipart/form-data requests. Is that also the common practice for
multipart responses from servers?

Zhong Yu



On Mon, Apr 29, 2013 at 1:47 PM, Ben Niven-Jenkins
<ben@niven-jenkins.co.uk>wrote;wrote:

> Hi,
>
> 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.
>
> Thanks
> Ben
>
>
>