Résumé

  • 202 Accepted signifie que la demande a été acceptée pour traitement alors que celui-ci n’est pas terminé.
  • L’opération peut encore être refusée, annulée, expirer, perdre son autorisation ou se terminer sans produire l’effet attendu.
  • Toute décision qui dépend de l’achèvement exige un reçu d’opération asynchrone reliant la demande initiale au suivi de référence et au résultat final.

Imaginons un contrôleur de changement qui demande la rotation d’une politique d’accès. Le service renvoie 202 Accepted avec un lien vers l’opération. Le contrôleur déclare alors le changement terminé, révoque l’ancien identifiant et supprime les données d’entrée. Quelques minutes plus tard, la tâche arrive sur un processus d’exécution, qui vérifie de nouveau la politique et la refuse. La demande avait bien été acceptée. Le changement, lui, n’a jamais été exécuté.

L’erreur ne vient pas du code d’état. Elle consiste à transformer une étape d’une opération distribuée en preuve de toutes les étapes suivantes.

La définition de RFC 9110 est étroite. Une réponse 202 Accepted indique que le serveur a accepté la demande pour traitement, mais que ce traitement reste incomplet. La demande pourra être exécutée ou non : elle peut encore être interdite lorsque le traitement commence. La réponse est volontairement sans engagement sur l’issue.

Cette limite importe parce que l’échange HTTP est déjà clos. RFC 9110 précise qu’HTTP ne prévoit aucun mécanisme permettant de renvoyer, dans cet échange terminé, le code d’état ultérieur d’une opération asynchrone. Un client qui interprète le premier 202 comme une réussite finale invente donc une suite que le protocole n’a pas fournie.

La représentation jointe à la réponse devrait décrire l’état courant de la demande et renvoyer vers un dispositif de suivi, ou l’intégrer. Cette recommandation est utile, mais une URL ne constitue pas à elle seule un reçu d’achèvement. Le suivi doit faire autorité pour la même opération, être accessible dans le contexte de sécurité prévu, rester disponible pendant la durée utile à la décision et distinguer clairement les états finaux. Une page générique de file d’attente, une adresse « dernière tâche » dont la cible change ou un lien qui finit par répondre 404 ne peuvent pas porter toute cette preuve.

RFC 7240 ajoute un signal connexe, mais distinct. Le client peut envoyer Prefer: respond-async pour exprimer sa préférence en faveur d’un traitement asynchrone, et le serveur peut y répondre par 202 Accepted. Cette préférence choisit un mode d’échange ; elle ne prouve pas que le travail différé a été effectué. La spécification laisse à chaque mise en œuvre le soin de déterminer comment obtenir le résultat ultérieur.

Le champ Preference-Applied a une portée tout aussi limitée. Selon RFC 7240, il peut indiquer quelles préférences de la demande ont été respectées. Il peut donc confirmer que le serveur a choisi le traitement asynchrone. Il ne confirme ni le démarrage d’un processus, ni une écriture, ni une notification, ni un déploiement, ni aucun autre effet ultérieur.

Le dossier opérationnel doit préserver au moins trois faits différents. Le premier est l’acceptation : quels octets, quel principal, quelle cible, quelle clé d’idempotence et quelle réponse ont été observés, et depuis quel point. Le deuxième est l’exécution : quel identifiant d’opération est entré dans quelle file, quel processus l’a pris en charge, quels contrôles d’autorisation et de dépendance étaient alors à jour, et si une annulation ou une expiration est intervenue. Le troisième est le résultat : quels effets ont été validés, quel état final a été rendu et si cet état fait toujours autorité.

Ces liens se perdent facilement. Une passerelle peut produire le 202 alors qu’un autre service possède la file. L’adresse de suivi peut désigner une tâche relative à un locataire et changer de sens avec d’autres identifiants. Une nouvelle tentative peut retrouver la même tâche, ou en créer une seconde en l’absence d’idempotence. Le processus peut démarrer après la révocation du droit d’agir. Un indicateur « réussi » peut être enregistré avant que l’effet en aval soit observable.

Aucun de ces cas ne rend 202 défectueux. L’acceptation asynchrone est justement utile parce que la connexion ne doit pas rester ouverte pendant un traitement long. La discipline consiste à conserver la réponse comme preuve d’acceptation, puis à demander des preuves ultérieures pour les affirmations ultérieures.

L’objet probant utile est un reçu d’opération asynchrone. Il relie la méthode, la cible et l’empreinte du corps de la demande à l’identité authentifiée, à l’état de son autorisation au moment considéré, à la clé d’idempotence, au point d’observation, à la réponse 202, à l’identifiant d’opération et au suivi de référence. Il enregistre ensuite l’entrée en file, la prise en charge par un processus, les contrôles récents d’autorisation et de dépendance, l’annulation, les identifiants des effets produits, le résultat final, l’heure d’observation et la décision qui s’est appuyée sur ce résultat.

Sources

RFC 9110 — HTTP Semantics, 202 Accepted ; RFC 7240 — Prefer Header for HTTP.