Résumé

  • Dans draft-ietf-httpbis-resumable-upload-12, Upload-Offset accuse réception du préfixe de la représentation déjà traité par la ressource temporaire et garantit qu’il ne faudra pas le retransmettre.
  • Cette garantie de continuité ne prouve ni l’achèvement explicite, ni l’intégrité, ni l’autorisation encore valable, ni la décision de la ressource cible ; l’exploitation doit conserver ces états séparément.

La connexion s’est rompue après l’envoi d’un dossier volumineux. Une heure plus tard, le client a interrogé la ressource de téléversement : presque tous les octets étaient toujours là. Il a repris au bon endroit, sans coût inutile, et le compteur a atteint la longueur annoncée.

Le tableau de bord a alors classé le dossier comme reçu. Pourtant, la ressource cible n’avait encore rendu aucune décision. Le contrôle de quota devait être refait, la représentation assemblée attendait son analyse et la dernière requête n’avait jamais déclaré l’achèvement.

La reprise avait fonctionné exactement comme prévu. C’est l’interprétation qui avait débordé.

La révision 12 de Resumable Uploads for HTTP, publiée le 6 juillet 2026, décrit un mécanisme HTTP pour reprendre les envois interrompus. Il s’agit d’un Internet-Draft actif du groupe HTTP, destiné au Standards Track et valable jusqu’au 7 janvier 2027. Ce n’est pas encore un RFC, un relevé de déploiement ou un résultat d’interopérabilité. Son architecture donne néanmoins une leçon nette : la preuve la plus fiable reste celle dont la portée n’est pas élargie après coup.

Deux ressources, deux responsabilités

La requête initiale vise une ressource qui porte le sens métier de l’opération. Elle peut créer un document, remplacer un artefact ou soumettre un dossier. Le mécanisme de reprise crée à côté une ressource temporaire, propre à une seule représentation. Celle-ci expose la progression, accepte les ajouts et peut être annulée.

La distinction est fondamentale. La ressource temporaire entretient la continuité d’un transfert. La cible décide ce que signifie le corps complet dans le contexte de la méthode et des champs reçus. Confondre les deux revient à donner au greffier du transport le pouvoir du décideur applicatif.

Le serveur peut supprimer la ressource temporaire dès l’achèvement ou la conserver quelque temps pour permettre au client, privé de la dernière réponse, d’en vérifier l’état. Sa disparition n’est donc pas un code universel de succès ou d’échec. Il faut une politique de conservation explicite et le reçu de la cible.

Le décalage mesure un traitement applicatif

Upload-Offset compte les octets de la représentation traités par la ressource de téléversement. Le texte distingue ce traitement des accusés de réception de la couche de transport. Des paquets peuvent être arrivés et avoir été acquittés sans que l’application les ait encore intégrés dans son état durable.

La valeur retournée constitue toutefois une promesse forte : le préfixe indiqué a été traité et ne devra pas être retransmis. Le client peut libérer le tampon correspondant ou abandonner une copie locale prévue uniquement pour une reprise. Cette économie est précisément le bénéfice du protocole.

Mais la promesse porte sur la retransmission, pas sur tout l’avenir des octets. Elle ne certifie pas une réplication géographique, une durée de conservation, une analyse de sécurité, un engagement de la cible ou une publication. Le système qui ajoute ces conclusions invente une autorité que le champ ne contient pas.

Le décalage ne doit jamais diminuer. Si le serveur perd une partie de l’état nécessaire, il doit désactiver la ressource et refuser de continuer. Il ne doit ni estimer le dernier point sûr ni revenir silencieusement à une valeur antérieure. La monotonie exige une discipline : mieux vaut rompre la continuité que la simuler.

Même longueur, état encore ouvert

La longueur décrit la taille de la représentation lorsqu’elle est connue. Le décalage indique le préfixe traité. Leur égalité paraît naturelle comme critère d’achèvement, mais le projet l’exclut expressément : un téléversement peut avoir offset == length et rester incomplet.

Le client doit annoncer l’achèvement, ou le serveur doit le marquer. Une source en flux peut avoir livré tout ce qu’elle connaît à un instant sans avoir fermé. Une stratégie en plusieurs requêtes peut avoir envoyé les octets puis utiliser une requête finale vide pour conclure. L’arithmétique n’accomplit pas cette cérémonie.

Upload-Complete porte donc un état autonome. Dans une réponse de création ou d’ajout, la valeur vraie indique que la sémantique de la ressource initialement visée s’applique ; la valeur fausse laisse l’échange dans le régime de reprise. Une réponse anticipée de la cible peut même rendre la valeur vraie avant la transmission de toute la représentation. « Complet » appartient au protocole, pas à une simple comparaison de compteurs.

Le 104 promet une porte de retour

Le code 104, Upload Resumption Supported, est provisoire. Il peut annoncer très tôt l’URI de la ressource temporaire et ses limites, puis communiquer un décalage pendant le traitement. Une coupure ultérieure ne force plus nécessairement le client à repartir de zéro.

Cette réponse ne clôt pas la requête originale. Si une interface l’affiche comme un succès final, elle transforme une capacité de reprise en résultat métier. Dans la stratégie optimiste, le client transmet immédiatement la représentation et espère recevoir le 104 assez tôt. Si un intermédiaire supprime la réponse provisoire ou si la coupure survient avant elle, l’état peut exister côté serveur sans coordonnées de reprise côté client.

La stratégie prudente crée d’abord une ressource vide, récupère son URI et ses limites, puis envoie les octets. Le prix est un aller-retour ; le gain est de connaître la clé de continuité avant de risquer un gros corps. Dans les deux cas, seule la réponse finale de la cible tranche l’opération.

Le conflit de décalage protège le dossier

Chaque ajout présente le décalage que le client croit courant. Si cette valeur ne correspond pas à l’état du serveur, celui-ci répond 409 Conflict avec son propre décalage et l’état d’achèvement. Le conflit empêche un retry tardif ou deux producteurs de juxtaposer silencieusement les mauvais fragments.

Il faut traiter le 409 comme une invitation à réconcilier les preuves, non comme une erreur à masquer. Le client relit l’état, vérifie l’identité de la représentation source et applique une règle explicite avant de reprendre. Renvoyer aveuglément le fragment peut le dupliquer ; imposer le compteur local peut ignorer un reçu déjà acquis.

Le projet interdit les transferts parallèles sur une même ressource de téléversement. La sérialisation réduit les courses, mais elle ne restitue pas une réponse finale perdue. Il reste nécessaire de concevoir l’idempotence de l’opération cible et la vérification après coup.

Assemblage, intégrité et sûreté

Un compteur de progression ne vérifie aucun condensat. Les champs de digest ont leurs propres règles : il faut savoir quelles données ils couvrent, à quel moment ils sont évalués et comment un échec ferme la procédure. La présence d’octets ne prouve pas leur identité.

La reprise fragmente aussi la vue des contrôles. Un scanner qui inspecte chaque PATCH comme un objet complet peut manquer une signature dangereuse répartie entre deux ajouts. La représentation assemblée doit être analysée avant exécution, publication ou remise à un parseur sensible. Les métadonnées restent elles aussi des entrées non fiables.

Cette séparation n’est pas du formalisme. Elle évite que le mécanisme conçu pour conserver les données permette aux données de contourner le contrôle qui n’existait qu’à l’échelle d’une requête unique.

Le temps use les permissions

Une ressource de reprise peut survivre longtemps. Entre sa création et sa finalisation, l’utilisateur peut perdre un rôle, dépasser son quota ou sortir du périmètre d’un dossier. Une autorisation valide à l’ouverture n’est pas une autorisation perpétuelle de conclure.

Le projet souligne ce risque de contrôle différé et recommande de vérifier encore les privilèges et quotas au moment de finaliser. Une URI difficile à deviner réduit l’exposition, mais ne remplace pas l’authentification, l’autorisation et une échéance. Le détenteur d’un lien de reprise possède une capacité technique limitée, pas une délégation sans fin.

Le registre d’exploitation doit donc conserver une échelle complète : octets transportés ; préfixe traité ; accord sur le décalage et la longueur ; achèvement explicite ; intégrité et politique de contenu ; autorisation actuelle ; engagement de la cible ; effet métier. Aucun échelon ne contient le suivant.

Sources et limites

Le dossier gelé réunit la révision 12, son historique Datatracker, la surface de travail HTTP, les RFC sur la sémantique et les versions HTTP, QUIC, les champs de digest, PATCH, Problem Details et Content-Disposition. Il établit les mécanismes et leurs limites, pas leur adoption, leur performance, un incident réel ou le comportement d’un fournisseur nommé.

Sources