- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 22 Jul 2014 09:03:02 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Greg Wilkins <gregw@intalio.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 22, 2014 at 5:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-07-22 08:16, Zhong Yu wrote:
>>
>> On Mon, Jul 21, 2014 at 11:03 PM, Greg Wilkins <gregw@intalio.com> wrote:
>>>
>>>
>>> On 22 July 2014 13:36, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>>>>
>>>>
>>>> What is the end-to-end semantics though? As far as the application is
>>>> concerned, the request-response cycle has the same semantics whether
>>>> or not 100-continue is exchanged under the hood.
>>>
>>>
>>>
>>> The semantic that the client application is seeking is confirmation from
>>> the
>>> origin server that it has inspected the headers and has consented for the
>>> body to be sent.
>>
>>
>> This is a new way of interpreting it, but it's probably not the
>> original intent, and it's not supported by the text of the spec. If a
>> server does not respond with 100, it doesn't mean the body is
>> forbidden to be sent; the client can always send the body regardless
>> of server response(s).
>> ....
>
>
> Instead of sending the 100, the server can immediately send a 4xx error
> code.
The client is still allowed to send the request body in that case:
http://tools.ietf.org/html/rfc7231#section-5.1.1
100-continue is a sufficient, but not necessary, precondition for the
request body. The mechanism allows opportunistic elision of the
request body, that's all.
If this is considered too weak, and H2 wants to strengthen the
semantics so that the client MUST wait for server approval before
sending the body, I'm all for it. But it is not the semantics of
100-continue in H1.
Zhong Yu
bayou.io
>
> Best regards, Julian
Received on Tuesday, 22 July 2014 14:03:30 UTC