Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

Loïc Hoguin <essen@ninenines.eu> Fri, 28 October 2016 08:34 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 2E6FE12947D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 28 Oct 2016 01:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.852
X-Spam-Level:
X-Spam-Status: No, score=-6.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, 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 VF9ABuhinCmQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 28 Oct 2016 01:34:48 -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 BCAE512945C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 28 Oct 2016 01:34:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c02YJ-0000h9-GO for ietf-http-wg-dist@listhub.w3.org; Fri, 28 Oct 2016 08:30:15 +0000
Resent-Date: Fri, 28 Oct 2016 08:30:15 +0000
Resent-Message-Id: <E1c02YJ-0000h9-GO@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <essen@ninenines.eu>) id 1c02YE-0007za-Gd for ietf-http-wg@listhub.w3.org; Fri, 28 Oct 2016 08:30:10 +0000
Received: from mout.kundenserver.de ([212.227.126.135]) by mimas.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <essen@ninenines.eu>) id 1c02Y7-0008DR-Tz for ietf-http-wg@w3.org; Fri, 28 Oct 2016 08:30:05 +0000
Received: from [192.168.0.101] ([77.122.110.220]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0M5tNd-1coZte1l8r-00xq09; Fri, 28 Oct 2016 10:29:35 +0200
To: Wenbo Zhu <wenboz@google.com>
References: <CAH9hSJZdBJ02+Z6o=aanZ=5PN=9VwyL1ZcX2jct-6f_FFivLGA@mail.gmail.com> <0f79ddf6-c455-c41a-f269-a1bdcef05b14@ninenines.eu> <CAH9hSJb2R9gv2vNqoyTjbMV4hZTYdpX2PoAoYgWUT1UuigLHRA@mail.gmail.com> <5541be74-afcc-6aef-404e-63acb2f608eb@ninenines.eu> <CAD3-0rOYZzp2mB3NYZwXvGPUxPz8GG+ih1binEajv3CJFCW-7Q@mail.gmail.com>
Cc: Takeshi Yoshino <tyoshino@google.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
From: Loïc Hoguin <essen@ninenines.eu>
Organization: Nine Nines
Message-ID: <97fa3a7c-473a-6014-732e-ef0879f5eb82@ninenines.eu>
Date: Fri, 28 Oct 2016 11:29:34 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAD3-0rOYZzp2mB3NYZwXvGPUxPz8GG+ih1binEajv3CJFCW-7Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:bm3MEv0Er0EyrEBSMDoqvvGTJqPZkNB8u6opl/X2VXpfaRJcy6L bzS4z/rQXQxhiZ0SYk71z5BjEmvsrwi6v4qIgR3XSaYyprh9l6FfO9+o0MyTs0sF8k6qI1q oNe/Y5VhRP1YGnbp/ivWvfOs06fho08fhjPyQ8nFHQycq+xnZigLpJX1cetvjJKTHytc1Gv iYRaANfIPdsd9Yt/hvueg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:UaVSm9zqnUc=:Z4A3p+v78vp8o2I+oIIhch 0cMHZL2xUnVwNbjAi6FPdkLCfy/Bxk2n1eUuiUw4zr3FjXwHd4dWqbd5nYQ4XerfNMZhlnX0M n+hp3WuQKgvn3kiAmny9+wCn3SQDklcChn3Mz6pPSkH52uZ4exoSkpFre/ykGzlT46rwbNSnk p73pl03GNtSUtOTOGl5eTqsvrTUAiPXR9p7t0dO/UOeTIJNOx9sOOTbVAMKAYsnqHKbp+7QH7 Y0lV1cwaUjlkYvAFUopmtsvjEPWEEhqQba4pylnsI2dmaoxle+RqO9TbhtA4ist/J6JdkKSQr 7hxJTddoPT1qhK53WSBwcxBVxo2m/GFA7B3VxkjcWCjXFxja/nKvjQBmAUHIZtBYE0SJr7//L 0b+TlkCcwA/16y2Nzq57EyZd3Vny/aG4HXOKaqk8sxaQQIsVk5Ae8oGMDnlwVO8FTHaK9XlcW 96TnX2zG5ptXRvWvvjVaAGhGzSEcTIMA7wXz7Bl4ieMO1Fh2kDIT4jFCVLX1TpIdgyP4g5Sht W/EvF9OpdRRV8tm1uNdhg2/qFhNS1JLeTN+PFWr8WWLfLq2m0ODK/5bEhQh9gtgOGKnwJjEmL K1uykv3kU9vNpTbNBf31FDNZ985nTOZvpOmr5D4doB26dwGd72guPMa3QdoQZmCDJ3YKsoVmM eJtfv2rg2aeWoFiZvKnX4+RJ5WmIebLrnijfJCkqHm5ffAmEPPBWCssjU7wrhAPxu1h+3N8sW 1PIMsl6P2TGbbwj0
Received-SPF: none client-ip=212.227.126.135; envelope-from=essen@ninenines.eu; helo=mout.kundenserver.de
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-1.750, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c02Y7-0008DR-Tz 7610dba443b61bf7277e158f576a5389
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <http://www.w3.org/mid/97fa3a7c-473a-6014-732e-ef0879f5eb82@ninenines.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32697
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 10/28/2016 04:04 AM, Wenbo Zhu wrote:
>     * The HEAD method behaves as usual. The PUT method is probably not
>     compatible with doing this. PATCH and DELETE are not compatible AFAIK.
>
> Not sure why a PUT/PATCH request can't have a streamed body.  I don't
> think we want to over-spec how to use HTTP with this media type (which
> is not the only stream-able media type either)

PUT can definitely have a streamed body, but protocols are a little more 
than that. PUT creates or replaces the resource with the enclosed 
representation, so whether PUT can be used depends on the protocol. If 
webstream is used like an event stream then there's definitely no 
problem; if it's used for MQTT the PUT semantics are lost.

PATCH expects a media type containing instructions on how to modify the 
resource, so again it depends on the protocol.

We should definitely not restrict it to specific methods, and that's not 
what I was trying to say. I was just trying to point out which methods 
should be mentioned in the document, even if only in an informative way 
or in examples.

A more general paragraph about request methods forbidding bodies should 
be more than enough to cover everything without going too much into the 
details of each method.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu