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

From: Ashok Kumar <[email-masked]>
Date: Mon, 14 Oct 2019 09:49:39 +0530

<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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 15 Oct 2019 00:14:06 +1300

> <Not sure why the mail is not getting distributed to httpbis>

FYI: This is the third copy this week to arrive here through the mailing
list. Looks like just nobody responding yet.

Looks like it may be an Errata to me. Though I do not know/recall why
the connection closure is only a SHOULD instead of a MUST.

AYJ

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 14 Oct 2019 09:09:01 -0700

> On Oct 13, 2019, at 9:19 PM, Ashok Kumar <[email-masked]> wrote:
> 
> 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>
> 
> 
>       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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Oct 2019 09:31:53 -0700

> the connection upon error instead of sending a body.
 I agree that's practical advice.. but due to race conditions I could see
the client having actually sent the whole body before processing the error
and there might not be a lot to be gained by throwing away the connection
in that case.. or perhaps more more obtrusely, the client might be able to
truncate the request body if it is chunking.. so the server should be
prepared for the possibility of reuse (unless it marks the connection
closed itself).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 14 Oct 2019 12:57:16 -0700

> On Oct 14, 2019, at 9:31 AM, Patrick McManus <[email-masked]> wrote:
> 
> 
> On Mon, Oct 14, 2019 at 9:09 AM Roy T. Fielding <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  I agree that's practical advice.. but due to race conditions I could see the client having actually sent the whole body before processing the error and there might not be a lot to be gained by throwing away the connection in that case..

Right, which is why it is specified this way instead of requiring either side to close.

To be clear, when the server doesn't indicate the connection is closed:
a client continuing to send a whole message before sending their next
request is the "okay" case, and terminating the connection upon receipt
of the 4xx code is the "normal" case, whereas sending a new request on the
same connection before completing the prior request's framing would be a bug
in the client.

> or perhaps more more obtrusely, the client might be able to truncate the request body if it is chunking.. so the server should be prepared for the possibility of reuse (unless it marks the connection closed itself).

Also true, in the rare cases that allow use of chunked request bodies, that
sending a zero chunk early is fine because the request semantics no longer
matter (we are sending data for the sole purpose of delimiting the message).

However, due to the complexity and race conditions inherent in Expect 100
processing, clients avoid using it except in those conditions where there is a
very clear advantage to waiting a RTT for the 100 instead of risking a wasted
body send. Anything close to borderline is usually sent without Expect.

Hence, clients do not typically finesse the error handling even when they can
(except maybe for Patrick's client, because it's an interesting challenge ;-).

....Roy

---

From: Rob Sayre <[email-masked]>
Date: Tue, 15 Oct 2019 13:40:11 +0700

On Tue, Oct 15, 2019 at 3:00 AM Roy T. Fielding <[email-masked]> wrote:

>
> Also true, in the rare cases that allow use of chunked request bodies
>

That used to be pretty common on mobile when 3G was the best networking
speed available. I haven't checked lately.

thanks,
Rob