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

Ashok Kumar <ashokkumarj@gmail.com> Mon, 14 October 2019 04:22 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 8C6901200A3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Oct 2019 21:22:37 -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 (2048-bit key) header.d=gmail.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 8_4v6ydtBD6e for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Oct 2019 21:22:36 -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 114B612002E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 13 Oct 2019 21:22:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iJrpq-0003oQ-KZ for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Oct 2019 04:19:54 +0000
Resent-Date: Mon, 14 Oct 2019 04:19:54 +0000
Resent-Message-Id: <E1iJrpq-0003oQ-KZ@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 <ashokkumar.j@gmail.com>) id 1iJrpo-0003ne-Sm for ietf-http-wg@listhub.w3.org; Mon, 14 Oct 2019 04:19:52 +0000
Received: from mail-qt1-x836.google.com ([2607:f8b0:4864:20::836]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <ashokkumar.j@gmail.com>) id 1iJrpn-0007AU-C1 for ietf-http-wg@w3.org; Mon, 14 Oct 2019 04:19:52 +0000
Received: by mail-qt1-x836.google.com with SMTP id v52so23585837qtb.8 for <ietf-http-wg@w3.org>; Sun, 13 Oct 2019 21:19:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n2e2FFb9lRebrKJAU7AbaLOn8equHqowiSQz2yYZN4M=; b=q8B8vFBNRI73TgN8PnVpanudhWZ/e31cdQPQE9l0zMo5o3SDI4or6tB6NEsL613h08 eO2ct/4sOPgmHCvhs0hFqBkmaHH72WuCWqB8qM0lG6DU6diGp1jZrXGLB8vAaFGtOxX7 KfEJu2pPiESDb3xZQGyP7sZrBlS3NMAsgIbg9vL6rUc7Vz4y3IEWZdH+TMBcqO9yttf7 MOx0ZTl6Vra1X05cegd+di+TePlJmbICgYiSZln2gQSLYxU9Bo54Xq502xc6Iu84WtAh PGJaxFEpg8wOVkrk2CcYna0UGVAXWB+L1V5Gt7nFbRLGc27t9CW7WUrEek28seTASe9Y ZIDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n2e2FFb9lRebrKJAU7AbaLOn8equHqowiSQz2yYZN4M=; b=RzxlOJEK+9VgBML8zmYJcBcdeX5GAqngTOsc9EC7jHPxhl6W1qONC9Qr/bOY4GXTNS q13b8rENuOGaltMw53oh3oukOJtusx0XzAIGCGIKtaUlPGNZVcmtQQDu95Gs+1mQt7jK zVSq67UYiquvDxCLtmM2LuhzM82x7iAiC8Ks83UVMo+FVpW86cUpfkDowcN4eFg2d+TL 2uNo0T/TIZoyBLr7F+AehZKuMbBVCMwemY/CLQ9WzWlxKBmARwx09Pwq3+kUBFWh6wGL 4Q81Lj+YsGY11pqVDTSmYTEtx5Ug4t3D2vY4+pOZrFgQBseAJfFonqp9jrfDp2EH+rUp OXkw==
X-Gm-Message-State: APjAAAWcs5KiwBJtdGrOccC1Ihm52AZsWeNNqeUH4+NSRtGzI9fHCEcj SAsh/fQiXOngzwtMP8JWoYje/UQBE01bPXng1dKvby2w
X-Google-Smtp-Source: APXvYqzaKenxBx736cqao/FBuiclmQDtdeh1I6H71LYZhTuhvLVgk2ipSihqSgKCVtXg2eGUq7FCrCgH8D/6t6BH/04=
X-Received: by 2002:ac8:1408:: with SMTP id k8mr8670046qtj.327.1571026789960; Sun, 13 Oct 2019 21:19:49 -0700 (PDT)
MIME-Version: 1.0
From: Ashok Kumar <ashokkumarj@gmail.com>
Date: Mon, 14 Oct 2019 09:49:39 +0530
Message-ID: <CAOeYYRf5w-QT9qALtwnmXTcqSLybbGvO9N6G0AEzkk=tYkzMYQ@mail.gmail.com>
To: ietf-http-wg@w3.org, http-use@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bf8fb20594d72de6"
Received-SPF: pass client-ip=2607:f8b0:4864:20::836; envelope-from=ashokkumar.j@gmail.com; helo=mail-qt1-x836.google.com
X-W3C-Hub-Spam-Status: No, score=-1.6
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1iJrpn-0007AU-C1 579d6c67eab045d3b9d81727623dcf07
X-Original-To: ietf-http-wg@w3.org
Subject: 401 response from server on Expect 100 continue and re-using the connection
Archived-At: <https://www.w3.org/mid/CAOeYYRf5w-QT9qALtwnmXTcqSLybbGvO9N6G0AEzkk=tYkzMYQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37050
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>

<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


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?


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?


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.


Thanks in advance,

Ashok