Re: p2: Expect: 100-continue and "final" status codes

"Adrien W. de Croy" <> Wed, 24 April 2013 04:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D51421F9318 for <>; Tue, 23 Apr 2013 21:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7jDhTfd9-dNk for <>; Tue, 23 Apr 2013 21:40:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2755A21F9322 for <>; Tue, 23 Apr 2013 21:40:53 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUrUh-0007S6-Te for; Wed, 24 Apr 2013 04:39:47 +0000
Resent-Date: Wed, 24 Apr 2013 04:39:47 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUrUc-0007RR-5o for; Wed, 24 Apr 2013 04:39:42 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUrUa-0006Tu-F7 for; Wed, 24 Apr 2013 04:39:42 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.0.0 (Build 4539)) with SMTP id <>; Wed, 24 Apr 2013 16:39:16 +1200
From: "Adrien W. de Croy" <>
To: "Mark Nottingham" <>, "Amos Jeffries" <>
Cc: "" <>
Date: Wed, 24 Apr 2013 04:39:16 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <>
Message-Id: <em371a6470-eea5-4b2a-8741-d2e3c419f0ed@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <>
User-Agent: eM_Client/5.0.17595.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.0
X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UUrUa-0006Tu-F7 442f150ca4f38647608006fa8902fa03
Subject: Re: p2: Expect: 100-continue and "final" status codes
Archived-At: <>
X-Mailing-List: <> archive/latest/17519
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

------ Original Message ------
From: "Mark Nottingham" <>
>On 24/04/2013, at 12:41 PM, Amos Jeffries <> wrote:
>>>>  I think we can give better advice than that. If a server responds 
>>>>with a final status code instead of 100 (Continue)
>>>>  1. The response must be the last response on the connection. The 
>>>>response should contain "Connection: close" header. After the 
>>>>response is written, the server must initiate a lingering close of 
>>>>the connection (p1#6.6).
>>>  That seems too restrictive; as long as the server reads the rest of 
>>>the request properly (discarding it), it should be able to recover 
>>>and reuse the connection.
>>  The problem comes with intermediaries. How are they to know the bytes 
>>following were the original advertised payload or not? the status from 
>>server has no guarantee of arriving after the client payload starts 
>>  The only way to guarantee safety on the connection is to close it or 
>>always send payload.

I'm really struggling to see what benefit can be derived by a client in 
knowing whether a server supports 100 continue or not.  So to me 
Expects: 100-continue is a complete waste of space.  I've never seen one 
so I guess implementors by and large agree.

Regardless of 100 continue being transmitted, the client has to send the 
payload if it wants to reuse the connection.  The only early-out options 
involve closing the connection.

There was quite a lot of discussion about this in the past, and my 
understanding was that 100 continue couldn't be used to negotiate 
whether or not the payload would be sent.  The outcome of this 
discussion was not satisfactory IMO, since the "answer" was for the 
client to send request bodies always chunked, and send a 0 chunk if it 
needed to abort early.

This IMO is unsatisfactory because it does not indicate that the client 
didn't send the payload, and a whole heap of intermediary agents may act 
on that as if it were complete.

So for me therefore there's still a hole in the spec around this - 
chunking doesn't have a way to indicate aborting the body.  And there's 
no way to pre-authorization transmission of a request body.

I don't see how a server can return a success status code to a message 
it didn't even receive yet.  Returning a 417 due to expectation not met 
is just extra noise and RTT, and the connection needs to be closed 
anyway or the payload sent.

So, what would we really lose if 100-continue were deprecated?  and what 
would we gain.

Some servers send it on every POST, regardless.  This has some 
significant cost.  What's the real benefit?


>Mark Nottingham