W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

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

From: Ashok Kumar <ashokkumarj@gmail.com>
Date: Thu, 10 Oct 2019 14:58:34 +0530
Message-ID: <CAOeYYRdHfjHxr89ecT4deyncZdTRDxEH5T1W99Tb4D7Dowhwiw@mail.gmail.com>
To: ietf-http-wg@w3.org
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
Received on Thursday, 10 October 2019 14:05:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC