- From: Rui Prior <rprior@dcc.fc.up.pt>
- Date: Tue, 18 Nov 2014 18:33:52 +0000
- To: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, Takeshi Yoshino <tyoshino@google.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
> I think there are several different scenarios under consideration. > > 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. Depends on what exactly "closing the stream" does: (1) Closing the stream includes closing the the TCP connection => the body of the HTTP message is incomplete, so the server should avoid processing it; no response is returned. (2) Closing the stream includes half-closing the the TCP connection => the body of the HTTP message is incomplete, so the server should avoid processing it; a 400 Bad Request response would be adequate. (In particular cases where partial bodies would be acceptable, perhaps it might be different.) (3) Closing the stream does nothing with the underlying TCP connection => the server will wait for the remaining bytes (perhaps until a timeout). > 2. The author says Content-Length 100, writes 50 bytes, and never closes the stream. The server will wait for the remaining bytes (perhaps until a timeout). > 3. The author says Content-Length 100, writes 150 bytes, then closes the stream. The server thinks that the message is finished after the first 100 bytes and tries to process them normally. The last 50 bytes are interpreted as the beginning of a new (pipelined) request, and the server will generate a 400 Bad Request response. > 4. The author says Content-Length 100 , writes 150 bytes, and never closes the stream. This case should be similar to the previous one. IMO, exposing such degree of (low level) control should be avoided. In cases where the size of the body is known beforehand, Content-Length should be generated automatically; in cases where it is not, chunked encoding should be used. Rui Prior
Received on Tuesday, 18 November 2014 18:34:21 UTC