401 response on Expect 100 continue and re-using the connection
Ashok Kumar <ashokkumarj@gmail.com> Thu, 10 October 2019 14:07 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 8741D1200C1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 10 Oct 2019 07:07:32 -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 (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 1tsOdvTrSONc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 10 Oct 2019 07:07:30 -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 E97AB120099 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 10 Oct 2019 07:07:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iIZ49-0002I3-Qu for ietf-http-wg-dist@listhub.w3.org; Thu, 10 Oct 2019 14:05:17 +0000
Resent-Date: Thu, 10 Oct 2019 14:05:17 +0000
Resent-Message-Id: <E1iIZ49-0002I3-Qu@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) 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 1iIZ40-0002EW-92 for ietf-http-wg@listhub.w3.org; Thu, 10 Oct 2019 14:05:08 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <ashokkumar.j@gmail.com>) id 1iIZ40-0002x3-47 for ietf-http-wg@listhub.w3.org; Thu, 10 Oct 2019 14:05:08 +0000
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 1iIS4J-0005Yj-RE for ietf-http-wg@listhub.w3.org; Thu, 10 Oct 2019 06:36:59 +0000
Received: from mail-qk1-x736.google.com ([2607:f8b0:4864:20::736]) 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 1iIS4I-0008U7-9B for ietf-http-wg@w3.org; Thu, 10 Oct 2019 06:36:59 +0000
Received: by mail-qk1-x736.google.com with SMTP id p10so4596107qkg.8 for <ietf-http-wg@w3.org>; Wed, 09 Oct 2019 23:36:57 -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=U53SdQe3kRxczqn0SV46zgELfMKHsPb8PLCuDptg4Fk=; b=csI76JLF3vt78xRTdAjSPd5nYTPqXMcyuHRfoQtZp1x1dp9pz8EDd98qBlVVbDpd+q bb2u9Z6ydst4kS0RzYHEgZjEFU9LqjU7/jOrNmJ4xzXpW9UnRdK4Gcr2THkA76xnR6/v TL91j3RCpyNuRRW1/T1pgSsQrPVocubhHJL3B7slRtou0Ei3QeZs+8YYEROdpHAfm+EG SnH6fL7setVuB8IsyJuXbqCICTKt552Y4TikCxeIIXMOfq62N+6w54xBaRe1uMcS0OYN zwDxd6AZQpLPHXy2XlYpB5fBCRaUFz0BXGnNdiOlfthhrsqboodQeqfN0B2vrF0C2ePh BluA==
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=U53SdQe3kRxczqn0SV46zgELfMKHsPb8PLCuDptg4Fk=; b=H9JKXNNklCwnaB2SArFm1Y475gBlj4/HgAPI16GOFktezh3NKk3U/5cNiXbtDQYrdZ 6dOy8xALo/zGJe3JMYQUApKtlbglda9peR/JVxJFqirPvzK4hGoExw4qvpynV0LxGc/b cWKrl/v1q8QbXjljn+ZGkahDuBJgP+o3bP0kFRXPo0VmpGHUThXvVd37Cw6lPE5snr3D 5YNg6T/alLU5wQwNs8o6WkiLaYOlNdtfzQmsef8nZqnmwtPfB4vHtnrT33+m9CTNmbP5 itQjZXFd+uurISN3Pvf4080ohFJGnVu5JlYrKKFcoOQaCz6FFqTEw6hODWqwANNWgCSz wRqQ==
X-Gm-Message-State: APjAAAV7jDcufiv41k+6Yj5qfTERuAwG6zs9IM1RaiFP+d0QAKQv2APJ 1HXoGnW4BSIc+CxF+4Bjus976/rp+Hbo1GXbSKhC0fBQ
X-Google-Smtp-Source: APXvYqx/rSYXzJgGilAPIcFmPz/EZbhf+YeiXeM+wC5Y1s4LtbVeDBsXJ40kyaVelrd/PrYXoGKzDz4p+5oD/qVrozE=
X-Received: by 2002:a37:83c5:: with SMTP id f188mr1322887qkd.468.1570689416791; Wed, 09 Oct 2019 23:36:56 -0700 (PDT)
MIME-Version: 1.0
From: Ashok Kumar <ashokkumarj@gmail.com>
Date: Thu, 10 Oct 2019 12:06:45 +0530
Message-ID: <CAOeYYRdL1zdqJry6b+YpWttXyjJFKiVALJdEqmbuUsgMD_qpqQ@mail.gmail.com>
To: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000bd8c2f059488a0d4"
Received-SPF: pass client-ip=2607:f8b0:4864:20::736; envelope-from=ashokkumar.j@gmail.com; helo=mail-qk1-x736.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 1iIS4I-0008U7-9B 61f2d1e8e75558d47873dd3ba006015a
X-caa-id: 4d339d357c
X-Original-To: ietf-http-wg@w3.org
Subject: 401 response on Expect 100 continue and re-using the connection
Archived-At: <https://www.w3.org/mid/CAOeYYRdL1zdqJry6b+YpWttXyjJFKiVALJdEqmbuUsgMD_qpqQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37046
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>
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
- 401 response on Expect 100 continue and re-using … Ashok Kumar
- Re: 401 response on Expect 100 continue and re-us… Ashok Kumar