HTTP non funziona così. Il client invia una richiesta, quindi il server invia una risposta. Non si verificano altre comunicazioni Bene, il server può inviare risposte informative 1xx prima della risposta principale. Ma non c'è modo per il client di inviare aggiornamenti su una richiesta inviata.
(La situazione è molto diversa per HTTP / 2 che può multiplexare più richieste sulla stessa connessione.Un client può CANCELLARE un flusso per indicare che non è più necessario dopo aver ricevuto un PUSH_PROMISE dal server. HTTP / 2 per il resto di questa risposta.)
Inoltre, le reti non funzionano così. In particolare, vedi il secondo errore di calcolo distribuito : "la latenza è zero". Non è. Di quel secondo timeout, sono stati spesi 400 ms per stabilire la connessione e inviare la richiesta e 600 ms per la risposta, perché uno dei pacchetti è stato eliminato e si è dovuto inviare nuovamente tutto e il client è in Australia. A parte il problema che il server potrebbe non avere abbastanza tempo, il server non sa nemmeno quanto tempo hanno perché la latenza della risposta non può essere conosciuta in anticipo.
Quindi dato che l'implementazione letterale di questi timeout è impossibile, quale tipo di soluzione potrebbe essere abbastanza buona?
Se la risposta non avrà alcun valore dopo il timeout, il client può semplicemente chiudere la connessione. Ciò farà sì che la tua risposta sia ignorata, ma non impedirà la risposta.
La chiusura della connessione TCP su cui viene inviata la richiesta HTTP avverte il server. Ma questa notifica arriva solo con latenza, quindi potrebbe essere troppo tardi. Inoltre, il tuo framework web potrebbe non fare nulla quando il socket del client è chiuso. In tal caso verrebbe visualizzato un errore "connessione ripristinata dal peer" una volta che provi a scrivere sul socket chiuso.
Se non desideri dedicare più di un secondo all'elaborazione della risposta, l'implementazione di tale timeout è interamente a tuo carico e non ha nulla a che fare con il networking o l'HTTP.
Puoi chiedere al client di fornire un timeout al server, in modo che il server possa abortire se non è in grado di rispettare la scadenza. Questo può essere specificato come intestazione personalizzata o come parametro di query nell'URL. Questa scadenza dovrebbe essere un punto assoluto nel tempo e non una durata in modo che i ritardi di trasmissione consumino anche il tempo disponibile. Ma l'accuratezza al secondo è difficile: il server e il client devono essere sincronizzati con l'ora corretta e devono utilizzare un orologio adatto. A seconda della configurazione, ogni volta che la sorgente può essere spenta di 100 ms anche se configurata correttamente. Questo già mangia una parte significativa del tuo budget di tempo.