Re: #467: Expect: 100-continue and "final" status codes

Alex Rousskov <> Mon, 20 May 2013 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A8F821F95FC for <>; Mon, 20 May 2013 09:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EqvGfu81DUm8 for <>; Mon, 20 May 2013 09:45:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EFA2C21F95E9 for <>; Mon, 20 May 2013 09:45:31 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UeTCu-0005h3-7C for; Mon, 20 May 2013 16:45:08 +0000
Resent-Date: Mon, 20 May 2013 16:45:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UeTCh-0002RV-RL for; Mon, 20 May 2013 16:44:55 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UeTCc-0000gJ-UK for; Mon, 20 May 2013 16:44:55 +0000
Received: from [] (localhost []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r4KGiTfD030282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Mon, 20 May 2013 10:44:29 -0600 (MDT) (envelope-from
Message-ID: <>
Date: Mon, 20 May 2013 10:44:19 -0600
From: Alex Rousskov <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.761, RP_MATCHES_RCVD=-1.07, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UeTCc-0000gJ-UK c12d7e320981e4515b43a4e2569a1df2
Subject: Re: #467: Expect: 100-continue and "final" status codes
Archived-At: <>
X-Mailing-List: <> archive/latest/18040
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 05/17/2013 05:28 AM, Ken Murchison wrote:
> On 05/16/2013 10:47 PM, Mark Nottingham wrote:
>> Note that this mechanism does not change the request message parsing
>> algorithm; in particular, whether or not a final response status code
>> is sent, the client still needs to send a complete request message. As
>> such, if a final status code is received, clients will often choose to
>> close the connection, rather than send a complete request (e.g., if it
>> is length-delimited). 

"the client needs to send a complete message" is perhaps too strong.
"the client needs to send a complete message if the client wants to keep
the connection open and the server response allows for a persistent
connection" may be more appropriate.

> This is an important point that I completely missed from any reading of
> 2616 and the current httpbis.  I assumed that if the server responded
> with a final status code before sending 100-continue, that the client
> would not send the body.

Keep in mind that by the time the origin server sends a response (any
status code), the client may have already started sending the request.
And intermediaries may see a different order of those two events.

> If I read your proposed text properly, the only way for a client to
> avoid sending the body of a failed conditional request while maintaining
> a persistent connection is to send the request using e/c and te/chunked,
> and just send a zero-length chunk after receiving the final response
> code.  Correct?

I do not think sending last-chunk prematurely is a good idea because
there will be no way for the intermediaries (and the origin server) to
distinguish an incomplete request from a complete one. The origin server
MUST NOT perform the requested method after sending 417, but
intermediaries may not know that the server has sent the final status
code and, hence, may "perform" the requested method. Misrepresenting the
end of the request body may have nasty side effects in real world.

Terminating the connection is probably the only safe course of action
for the client that does not want to send the whole body.