Richiesta di svuotamento con ASP.NET server Web Core Kestrel

Nota

Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Avviso

Questa versione di ASP.NET Core non è più supportata. Per altre informazioni, vedere Criteri di supporto di .NET e .NET Core. Per la versione corrente, vedere la versione .NET 8 di questo articolo.

Importante

Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

Per la versione corrente, vedere la versione .NET 9 di questo articolo.

L'apertura di connessioni HTTP richiede molto tempo. Per HTTPS, è anche un uso intensivo delle risorse. Di conseguenza, Kestrel tenta di riutilizzare le connessioni in base al protocollo HTTP/1.1. Un corpo della richiesta deve essere completamente utilizzato per consentire il riutilizzo della connessione. L'app non usa sempre il corpo della richiesta, ad esempio le richieste HTTP POST in cui il server restituisce una risposta di reindirizzamento o 404. Nel caso di reindirizzamento HTTP POST:

• È possibile che il client abbia già inviato parte dei dati POST.
• Il server scrive la risposta 301.
• La connessione non può essere usata per una nuova richiesta fino a quando i dati POST del corpo della richiesta precedente non sono stati letti completamente.
• Kestrel tenta di svuotare il corpo della richiesta. Svuotare il corpo della richiesta significa leggere ed eliminare i dati senza elaborarli.

Il processo di svuotamento rende un compromesso tra consentire il riutilizzo della connessione e il tempo necessario per svuotare i dati rimanenti:

• Lo svuotamento ha un timeout di cinque secondi, che non è configurabile.
• Se tutti i dati specificati dall'intestazione Content-Length o Transfer-Encoding non sono stati letti prima del timeout, la connessione viene chiusa.

In alcuni casi può essere necessario terminare la richiesta immediatamente, prima o dopo la scrittura della risposta. Ad esempio, i client possono avere limiti di dati restrittivi. La limitazione dei dati caricati potrebbe essere una priorità. In questi casi per terminare una richiesta, chiamare HttpContext.Abort da un controller, Razor una pagina o un middleware.

Ci sono avvertenze per chiamare Abort:

• La creazione di nuove connessioni può essere lenta e costosa.
• Non è garantito che il client abbia letto la risposta prima della chiusura della connessione.
• La chiamata Abort deve essere rara e riservata a casi di errore gravi, non errori comuni.
  • Chiamare Abort solo quando è necessario risolvere un problema specifico. Ad esempio, chiamare Abort se i client malintenzionati tentano di inviare dati POST o quando si verifica un bug nel codice client che causa richieste di grandi dimensioni o più richieste.
  • Non chiamare Abort per situazioni di errore comuni, ad esempio HTTP 404 (Non trovato).

La chiamata a HttpResponse.CompleteAsync prima della chiamata Abort garantisce che il server abbia completato la scrittura della risposta. Tuttavia, il comportamento del client non è prevedibile e potrebbe non leggere la risposta prima che la connessione venga interrotta.

Questo processo è diverso per HTTP/2 perché il protocollo supporta l'interruzione dei singoli flussi di richiesta senza chiudere la connessione. Il timeout di scarico di cinque secondi non si applica. Se sono presenti dati sul corpo della richiesta non letti dopo aver completato una risposta, il server invia un frame HTTP/2 RST. I frame di dati del corpo della richiesta aggiuntivi vengono ignorati.

Se possibile, è preferibile che i client usino l'intestazione della richiesta Expect: 100-continue e attendere che il server risponda prima di iniziare a inviare il corpo della richiesta. Ciò consente al client di esaminare la risposta e interrompere prima di inviare dati non necessario.