Subject: 100 Continue clarification

From: Olivier Boel EXT <[email-masked]>
Date: Thu, 9 Apr 2020 12:42:24 +0000

The below email is classified: Internal

Hello,

I have some doubts regarding how client should act in case server replies to "Expect: 100 Continue" with a final status (> 199).
RFC says: 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.
I would translate "whether it intends to close the connection" into "Connection: close" and "continue reading and discarding the request message" into "Connection: keep-alive".
In this latter case, IMHO, as the server already sent a final status (meaning "the request-line and header fields are sufficient to cause an immediate success, redirect, or error response"), client should understand it is not worthwhile to send the message body before actually doing so (which can improve efficiency when the message body is huge or when the client anticipates that an error is likely) even though server says "Connection: keep-alive", but rather send the next request.
Otherwise, the only way for the server to prevent the client sending the message body is to close the connection, which is rather drastic and not so in line with HTTP/1.1.
Can anyone clarify this?

Thanks,

Olivier B.
-----------------------------------------
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
ist nicht gestattet.

The information contained in this message is confidential or protected by
law. If you are not the intended recipient, please contact the sender and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/
Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
http://deutsche-boerse.com/letterhead

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 10 Apr 2020 13:04:51 +0200

Hello,

On Thu, Apr 09, 2020 at 12:42:24PM +0000, Olivier Boel EXT wrote:
> as the server already sent a final status (meaning "the request-line and
> header fields are sufficient to cause an immediate success, redirect, or
> error response"), client should understand it is not worthwhile to send the
> message body before actually doing so (which can improve efficiency when the
> message body is huge or when the client anticipates that an error is likely)
> even though server says "Connection: keep-alive", but rather send the next
> request.

This is not possible in HTTP/1 because the framing depends on the body
to reach its end. At best if the client uses the chunked transfer coding
then it may perform an early abort by completing the current chunk and
sending the zero-sized chunk to mark the end of the transfer. But as
long as XXX bytes were promised in content-length there is no way the
client can abort this and keep the connection alive: how would the
server know that finally those bytes will not come ? All the server
knows in such a case is that everything that follows the headers for
XXX bytes is supposed to be the request's body, and that it's only
after these ones that a new request may appear.

Hoping this helps,
Willy