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

"Roy T. Fielding" <fielding@gbiv.com> Mon, 14 October 2019 16:11 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 7FE88120820 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Oct 2019 09:11:48 -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=unavailable 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 xML_IBqf7Bgf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Oct 2019 09:11:47 -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 142E8120862 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Oct 2019 09:11:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iK2uH-0001TY-LX for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Oct 2019 16:09:13 +0000
Resent-Date: Mon, 14 Oct 2019 16:09:13 +0000
Resent-Message-Id: <E1iK2uH-0001TY-LX@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <fielding@gbiv.com>) id 1iK2uG-0001Rm-7J for ietf-http-wg@listhub.w3.org; Mon, 14 Oct 2019 16:09:12 +0000
Received: from blue.elm.relay.mailchannels.net ([23.83.212.20]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fielding@gbiv.com>) id 1iK2uD-0006Ki-WA for ietf-http-wg@w3.org; Mon, 14 Oct 2019 16:09:12 +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 5BA785A0B55; Mon, 14 Oct 2019 16:09:05 +0000 (UTC)
Received: from pdx1-sub0-mail-a5.g.dreamhost.com (100-96-4-204.trex.outbound.svc.cluster.local [100.96.4.204]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AF7A05A17C1; Mon, 14 Oct 2019 16:09:04 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a5.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 16:09:05 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Imminent-Suffer: 7d20c4e80c6bfa65_1571069345120_995213146
X-MC-Loop-Signature: 1571069345120:3063564857
X-MC-Ingress-Time: 1571069345119
Received: from pdx1-sub0-mail-a5.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a5.g.dreamhost.com (Postfix) with ESMTP id 193E97FEC7; Mon, 14 Oct 2019 09:09:04 -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=XbPayBRNfNgK3GLd1+P5pwm1PuU=; b= Lxvs+alcynBJPFB1bAmZUT1LrYcZlLqn5tqiACSLStTzJ5skoZ6XaBGxr7CF/YaR Qg2wi7bp2/oX9xe7I2OheeZy1xIelBVQmYwOb2lYMeEZbtyvYSCLUoQJECMYWZ8s lxrDxIhOOrftMy6xE8zqSvVNUomg46bBIBy5oQ9YZIM=
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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 259197FF55; Mon, 14 Oct 2019 09:09:02 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a5
From: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <C1810364-E6F8-488E-9E46-58B16393F5D6@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_913CCC41-5136-44CA-9BF1-F76CED1B9E47"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 14 Oct 2019 09:09:01 -0700
In-Reply-To: <CAOeYYRf5w-QT9qALtwnmXTcqSLybbGvO9N6G0AEzkk=tYkzMYQ@mail.gmail.com>
Cc: ietf-http-wg@w3.org, http-use@ietf.org
To: Ashok Kumar <ashokkumarj@gmail.com>
References: <CAOeYYRf5w-QT9qALtwnmXTcqSLybbGvO9N6G0AEzkk=tYkzMYQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=23.83.212.20; envelope-from=fielding@gbiv.com; helo=blue.elm.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: mimas.w3.org 1iK2uD-0006Ki-WA d638c29afbfd4f5f7ac386c9def10040
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 401 response from server on Expect 100 continue and re-using the connection
Archived-At: <https://www.w3.org/mid/C1810364-E6F8-488E-9E46-58B16393F5D6@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37052
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 13, 2019, at 9:19 PM, Ashok Kumar <ashokkumarj@gmail.com>; wrote:
> 
> <Not sure why the mail is not getting distributed to httpbis>
> 
> Hi,
> 
> I'm looking for some clarity on client behavior (or what the server should expect) in case of requests with "Expect: 100-Continue" header and final response from server (401 in particular).
> 
> https://tools.ietf.org/html/rfc7231#section-5.1.1 <https://tools.ietf.org/html/rfc7231#section-5.1.1>
> 
> 
> 5.1.1 <https://tools.ietf.org/html/rfc7231#section-5.1.1>;.  Expect
> 
> ~~
>  o  A client that sends a 100-continue expectation is not required to
>       wait for any specific length of time; such a client MAY proceed to
>       send the message body even if it has not yet received a response.
>       Furthermore, since 100 (Continue) responses cannot be sent through
>       an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
>       indefinite period before sending the message body.
> 
> ~~
> o  A server that responds with a final status code before reading the
>       entire message body SHOULD indicate in that response whether it
>       intends to close the connection or continue reading and discarding
>       the request message (see Section 6.6 of [RFC7230] <https://tools.ietf.org/html/rfc7230#section-6.6>).
> 
> 
> Does this imply that a client that sent "Expect: 100-continue", on receiving a final status code like 401, without a connection close, if it wishes to re-use the connection, MUST continue to send the response body?

Yes.

> Or put other way, Can server always assume that it will receive the request body on connecton where it sent a 401, before receiving the next request?

The server won't recognize bytes as a request until it has finished receiving a body.

> 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.

....Roy