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

Loïc Hoguin <> Fri, 28 October 2016 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E6FE12947D for <>; Fri, 28 Oct 2016 01:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.852
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VF9ABuhinCmQ for <>; Fri, 28 Oct 2016 01:34:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCAE512945C for <>; Fri, 28 Oct 2016 01:34:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c02YJ-0000h9-GO for; Fri, 28 Oct 2016 08:30:15 +0000
Resent-Date: Fri, 28 Oct 2016 08:30:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c02YE-0007za-Gd for; Fri, 28 Oct 2016 08:30:10 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c02Y7-0008DR-Tz for; Fri, 28 Oct 2016 08:30:05 +0000
Received: from [] ([]) by (mreue005) with ESMTPSA (Nemesis) id 0M5tNd-1coZte1l8r-00xq09; Fri, 28 Oct 2016 10:29:35 +0200
To: Wenbo Zhu <>
References: <> <> <> <> <>
Cc: Takeshi Yoshino <>, " Group" <>
From: Loïc Hoguin <>
Organization: Nine Nines
Message-ID: <>
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: <>
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=;;
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: 1c02Y7-0008DR-Tz 7610dba443b61bf7277e158f576a5389
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <>
X-Mailing-List: <> archive/latest/32697
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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.


Loïc Hoguin