Re: [Http-use] 401 response from server on Expect 100 continue and re-using the connection

"Roy T. Fielding" <fielding@gbiv.com> Mon, 14 October 2019 20:00 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 D67D9120871 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Oct 2019 13:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
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 qnjnIAv5ei0j for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Oct 2019 13:00:05 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66EA12011B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Oct 2019 13:00:05 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iK6TC-00018B-Cr for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Oct 2019 19:57:30 +0000
Resent-Date: Mon, 14 Oct 2019 19:57:30 +0000
Resent-Message-Id: <E1iK6TC-00018B-Cr@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <fielding@gbiv.com>) id 1iK6TB-00017L-1S for ietf-http-wg@listhub.w3.org; Mon, 14 Oct 2019 19:57:29 +0000
Received: from crocodile.birch.relay.mailchannels.net ([23.83.209.45]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fielding@gbiv.com>) id 1iK6T8-0006cj-Pj for ietf-http-wg@w3.org; Mon, 14 Oct 2019 19:57:28 +0000
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B8A7858087D; Mon, 14 Oct 2019 19:57:23 +0000 (UTC)
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-91-110.trex.outbound.svc.cluster.local [100.96.91.110]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 010DB5807EA; Mon, 14 Oct 2019 19:57:22 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a88.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Mon, 14 Oct 2019 19:57:23 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Harbor-Tank: 72951fd26e17080d_1571083043482_1838298261
X-MC-Loop-Signature: 1571083043481:1579103194
X-MC-Ingress-Time: 1571083043481
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id 5F2A580455; Mon, 14 Oct 2019 12:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=gbiv.com; bh=4wy1YILRyjKjxGUtpzaNmwa0npA=; b= oRRSROA/SCYxBdPfubV9Ke7A5YFteSncWmxH8APPQEUyMr7qIV8qyx4Y9yd7Vrtm RqjK30lVJTdiRP+MoGjuvHq8o1Wxf+hCMu74433IyJ7ThKkXjSkO5GD+sAKipObV 15zJ8seAmnp0J3USXXsGfoTnx35o7zXwvHuuvGPHYAg=
Received: from [192.168.1.4] (ip68-228-81-25.oc.oc.cox.net [68.228.81.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 133AD8045E; Mon, 14 Oct 2019 12:57:16 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a88
From: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <7E18CC06-8790-4452-9D0C-4598DC3B6F11@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_39E1D878-15B5-4E19-8499-A31A3C5B70E5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 14 Oct 2019 12:57:16 -0700
In-Reply-To: <CAOdDvNohqmZbfSzLCx55Ajq8vXw4zn_Z7uGAWcjWbgRABRA+CA@mail.gmail.com>
Cc: Ashok Kumar <ashokkumarj@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: Patrick McManus <mcmanus@ducksong.com>
References: <CAOeYYRf5w-QT9qALtwnmXTcqSLybbGvO9N6G0AEzkk=tYkzMYQ@mail.gmail.com> <C1810364-E6F8-488E-9E46-58B16393F5D6@gbiv.com> <CAOdDvNohqmZbfSzLCx55Ajq8vXw4zn_Z7uGAWcjWbgRABRA+CA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=23.83.209.45; envelope-from=fielding@gbiv.com; helo=crocodile.birch.relay.mailchannels.net
X-W3C-Hub-Spam-Status: No, score=-9.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iK6T8-0006cj-Pj 056069bd8752ba446083d48d41b13e0d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Http-use] 401 response from server on Expect 100 continue and re-using the connection
Archived-At: <https://www.w3.org/mid/7E18CC06-8790-4452-9D0C-4598DC3B6F11@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37054
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Oct 14, 2019, at 9:31 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> 
> On Mon, Oct 14, 2019 at 9:09 AM Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>> wrote:
> 
>> I see some clients which are behaving differently i.e. sending the next request on receiving a 401 and I'm unable to ascertain If this is correct.
> 
> That would depend on the method and body length, but for practical purposes
> an HTTP/1.1 client will only send "Expect: 100-continue" if they intend to close
> the connection upon error instead of sending a body.
> 
> 
>  I agree that's practical advice.. but due to race conditions I could see the client having actually sent the whole body before processing the error and there might not be a lot to be gained by throwing away the connection in that case..

Right, which is why it is specified this way instead of requiring either side to close.

To be clear, when the server doesn't indicate the connection is closed:
a client continuing to send a whole message before sending their next
request is the "okay" case, and terminating the connection upon receipt
of the 4xx code is the "normal" case, whereas sending a new request on the
same connection before completing the prior request's framing would be a bug
in the client.

> or perhaps more more obtrusely, the client might be able to truncate the request body if it is chunking.. so the server should be prepared for the possibility of reuse (unless it marks the connection closed itself).

Also true, in the rare cases that allow use of chunked request bodies, that
sending a zero chunk early is fine because the request semantics no longer
matter (we are sending data for the sole purpose of delimiting the message).

However, due to the complexity and race conditions inherent in Expect 100
processing, clients avoid using it except in those conditions where there is a
very clear advantage to waiting a RTT for the 100 instead of risking a wasted
body send. Anything close to borderline is usually sent without Expect.

Hence, clients do not typically finesse the error handling even when they can
(except maybe for Patrick's client, because it's an interesting challenge ;-).

....Roy