Is it acceptable for a server to send a HTTP response before the entire request has been received?

Consider a large HTTP request:

POST /upload HTTP/1.1
Content-Type: multipart/form-data
Content-Length: 1048576

...

The client now begins uploading a megabyte of data, which may take a while. However, the server determines that HTTP authorization is needed, so it decides it will respond with HTTP 401 Unauthorized.

MUST the server wait until it has received the entire request (IE, headers + CRLF CRLF + Content-Length bytes) before it can respond?

In practical terms, will such behavior break any browsers? Do browsers continue uploading the file anyway, or will they stop transmitting if they receive a 'premature' response?

More importantly, in this scenario, will they be able to successfully authenticate and begin the upload again (with credentials), or is it unreliable to cut off the upload like this?

Looking at RFC 2616 which defines the protocol, in Section 8.2.2 Monitoring Connections for Error Status Messages, it states

> An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body.

So I would say use you can jump in a send a 401 error. And then looking at 10.4.2 401 Unauthorized

> The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field

States that the client can retry with suitable credentials.

I haven't performed any experiments to see how browsers actually performed however.