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 16:09 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: http-use@ietfa.amsl.com
Delivered-To: http-use@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D31120860 for <http-use@ietfa.amsl.com>; Mon, 14 Oct 2019 09:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 VbwQkx4IQMJk for <http-use@ietfa.amsl.com>; Mon, 14 Oct 2019 09:09:09 -0700 (PDT)
Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (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 0B46012085A for <http-use@ietf.org>; Mon, 14 Oct 2019 09:09:06 -0700 (PDT)
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)
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-use/v3Z3o-hYb13ehbeyXdDNbNw4T-Q>
Subject: Re: [Http-use] 401 response from server on Expect 100 continue and re-using the connection
X-BeenThere: http-use@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion and review of IETF protocols that use HTTP and related Web technologies \(sometimes called \"RESTful\" protocols\)" <http-use.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-use>, <mailto:http-use-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-use/>
List-Post: <mailto:http-use@ietf.org>
List-Help: <mailto:http-use-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-use>, <mailto:http-use-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 16:09:12 -0000

> 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