Quel est le code d'état HTTP correct pour une demande annulée
Lorsqu'une connexion TCP est annulée par le client lors d'une requête HTTP, j'aimerais arrêter de travailler sur le serveur et renvoyer une réponse vide. Quel code d'état HTTP une telle réponse devrait-elle utiliser? revenir?
Pour être cohérent, je suggère 400 Bad Request maintenant, si vos applications dorsales sont capables d'identifier le moment où le client est déconnecté ou si vous rejetez ou fermez la connexion, vous pourriez probablement retourner le code non standard 499 ou 444 de Nginx.
499 Client Closed Request Utilisé lorsque le client a fermé la demande avant que le serveur puisse envoyer une réponse.
444 Aucune réponse Utilisé pour indiquer que le serveur n'a renvoyé aucune information au client et fermé la connexion.
HTTP (1.0/1.1) n'a aucun moyen d'annuler une demande. Tout ce qu'un client peut faire s'il ne veut plus de réponse est de fermer la connexion et d'espérer que le serveur contienne une optimisation pour arrêter de travailler sur une réponse qui ne peut plus être délivrée. Étant donné que la connexion est maintenant fermée, aucune réponse ni code d'état ne peuvent réellement être remis au client et donc tout code que vous "retournez" est uniquement pour votre propre satisfaction. Je choisirais personnellement quelque chose dans la gamme 4xx1 puisque la "faute" - la raison pour laquelle vous ne pouvez plus fournir de réponse - est due au client.
HTTP 2.0 permet à un point de terminaison d'émettre END_STREAM ou RST_STREAM pour indiquer qu'ils ne sont plus intéressés par un flux sans interrompre toute la connexion. Cependant, ils sont censés ignorer tout autre HEADERS ou DATA envoyé sur ce flux et donc même si vous pouvez théoriquement fournir un code d'état, le client va toujours l'ignorer complètement.
1Probablement 400 lui-même car je ne peux pas identifier une erreur plus spécifique qui semble tout à fait appropriée.
Il n'y a que quelques choix plausibles (à part 500, bien sûr):
202 Accepté
Vous n'avez pas terminé le traitement et vous ne le ferez jamais.
Cela n'est approprié que si, dans votre domaine d'application, le demandeur d'origine "s'attend" à ce que toutes les demandes ne soient pas satisfaites.
409 Conflit
… Entre faire et annuler la demande.
Ceci n'est que faiblement justifié: votre situation n'implique pas qu'un client fasse une demande sur la base d'informations périmées, car l'annulation ne s'est pas encore produite.
503 Service Indisponible
Le service n'est en effet pas disponible pour cette seule demande (car il a été annulé!).
L'argument général de "signaler une erreur comme une erreur" favorise 409 ou 503. Donc 503 c'est par défaut.
Il n'y a vraiment rien à faire. Citant de RFC 7230, section 6.5 :
Un client, un serveur ou un proxy PEUT fermer la connexion de transport à tout moment.
Cela se produit au niveau TCP, pas au niveau HTTP. Arrêtez simplement de traiter la connexion. Un code d'état ne donnera ici que peu de sens, car l'intention d'une demande incomplète/brisée n'est que pure spéculation. De plus, il n'y aura aucun moyen de le transporter jusqu'au client.