È accettabile che un server invii una risposta HTTP prima che sia stata ricevuta l'intera richiesta?

Question

consideri una grande richiesta HTTP:

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

... 

Il client ora inizia il caricamento di un megabyte di dati, che può richiedere un po '. Tuttavia, il server determina che è necessaria l'autorizzazione HTTP, quindi decide di rispondere con HTTP 401 Unauthorized.

DEVE attendere che il server abbia ricevuto l'intera richiesta (IE, intestazioni + CRLF CRLF + Content-Length byte) prima che possa rispondere?

In termini pratici, tale comportamento interromperà qualsiasi browser? I browser continuano a caricare il file in ogni caso, o interromperanno la trasmissione se ricevono una risposta "prematura"?

Ancora più importante, in questo scenario, saranno in grado di autenticare con successo e ricominciare il caricamento (con credenziali), o è inaffidabile interrompere il caricamento in questo modo?

Answer 1

Guardando RFC 2616, che definisce il protocollo, nella sezione 8.2.2 Monitoraggio delle Connessioni per segnalazioni di stato Errore, si afferma

Un HTTP/1.1 (o successivo) client che invia un messaggio-corpo dovrebbe monitorare la connessione di rete per uno stato di errore mentre sta trasmettendo la richiesta. Se il cliente vede uno stato di errore, DOVREBBE immediatamente interrompere la trasmissione del corpo.

Quindi direi che è possibile inserire un errore di invio 401. E poi guardando 10.4.2 401 Non autorizzato

La richiesta richiede l'autenticazione dell'utente. La risposta DEVE includere un campo di intestazione Autenticato WWW (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il cliente PU MAY ripetere la richiesta con un campo di intestazione di autorizzazione appropriato

Dichiara che il client può riprovare con credenziali adeguate.

Non ho eseguito alcun esperimento per vedere come i browser effettivamente sono stati eseguiti.