5

In the HTTP/1.1 standard, is it explicitly allowed or forbidden for a server to send a response before all the request's data have been received?

As an example, when uploading a large amount of data with a POST request, I may imagine the server returning a "202 ACCEPTED" response after receiving the request's header, but before having received the entire body. Would it be legal or not? Is this something existing out in the wild?

Strongly related to Is it acceptable for a server to send a HTTP response before the entire request has been received?, but the response there seems to focus on processing "errors" (4xx, 5xx maybe), not "success" (2xx)

Sylvain Leroux
  • 50,096
  • 7
  • 103
  • 125
  • 2
    I don't know about the spec, but it seems natural that the "success" response should be send only after fully receiveing the request. After all, the error might be somewhere at the end of the body, it would be weird to assume it is going to be correct. This is in contrast to "error" case which we can detect and react to early. And most clients (including browsers) will assume that, so either will process the response after request is send, or will fail completely on early response. In fact I think they will do that even in "error" case. – freakish Jun 27 '22 at 13:26
  • 3
    Have you considered *reading* the [`HTTP 1.1 standard`](https://www.ietf.org/rfc/rfc2616.txt)? Your question is answered there, at the beginning of Section 6, and that's where you should look. – user207421 Jul 01 '22 at 07:05
  • In any case it is completely impractical. RFC 2616 requires persistent connections by default, and an HTTP server can't read a 2nd or subsequent request unless it has already read all of the prior request, and if instead of persisting the connection it closes it with unread data, the connection will be reset by TCP which can cause loss of outgoing response data. So it isn't implementable, whether required or not. – user207421 Jul 01 '22 at 09:29
  • Thanks for your comments. But what about "100 continue". This message is sent before receiving the body. Is it a particularity of 1xx responses only? – Sylvain Leroux Jul 02 '22 at 16:06
  • From the http 1.1 standard p47: "The origin server MUST NOT wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it MAY close the transport connection or it MAY continue" Doesn't the statement *"if it responds with a final status code [...] it MAY continue"* implies the final code may be send before full request processing? – Sylvain Leroux Jul 02 '22 at 16:07

2 Answers2

3

Section 15.2 - You can send information responses before the requested action is completed.

i.e a 100 status indicates the request has been partially received but not all of it.

Andrew Lewis
  • 5,176
  • 1
  • 26
  • 31
3

In the HTTP/1.1 standard, is it explicitly allowed or forbidden for a server to send a response before all the request's data have been received?

Yes, it's allowed, though it depends on the situation.

For example, the server is allowed to send 1xx responses back prior to receiving the entirety of the request. We can conclude also that the server is not merely allowed to send 1xx responses, but is in fact encouraged to do so. The existence of an entire class of HTTP responses is not an accident – they were added to the spec explicitly for use in sending responses back to the client prior to request completion.

The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response.

For 2xx responses, the server should send these only if the entire request was received. This implies that the server does not (and should not) respond with a 2xx if the request has not yet been received.

The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.

There are other details about 3xx, 4xx, and 5xx, but with the above examples for 1xx and 2xx we can see that there are cases where the server can send a response before the request is complete, as well as cases where the server should not send a response before the request is received.

UPDATE:

Section 10.1.1 "100 Continue" from the HTTP/1.1 RFC contains this, which quite clearly describes the server responding mid-request:

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response.

Kaan
  • 5,434
  • 3
  • 19
  • 41