Téléverser une vidéo de deux gigaoctets via le Wi-Fi d'un café est un exercice d'optimisme. Vous regardez la barre de progression ramper vers les soixante-dix pour cent, puis la connexion vacille. Le téléversement échoue. Lorsque vous réessayez, le serveur attend un tout nouveau fichier. Vous repartez de zéro. Pour quiconque développe une application gérant des vidéos générées par les utilisateurs, ce n'est pas un cas particulier. C'est la norme. Le protocole tus a été conçu spécifiquement pour éradiquer ce problème. C'est un standard ouvert qui fonctionne sur l'HTTP ordinaire et donne une mémoire aux téléversements. Lorsque le réseau est rétabli, le transfert de fichier reprend exactement là où il s'était arrêté.
Pourquoi les téléversements standards échouent
Les téléversements de fichiers multipart standards traitent l'intégralité de la charge utile comme une transaction unique. Le navigateur ou l'application ouvre une connexion TCP, diffuse les octets et attend un code 200 OK à la fin. Si la connexion est réinitialisée parce que l'utilisateur est passé de la LTE au Wi-Fi, ou parce que l'ordinateur s'est mis en veille, le serveur n'a aucun moyen de savoir quels octets sont arrivés à bon port. La plupart des frameworks rejettent simplement les données partielles. L'utilisateur se retrouve avec un formulaire en échec et une mauvaise humeur. Les fichiers vidéo amplifient la douleur car ils sont volumineux, souvent téléversés depuis des appareils mobiles sur des réseaux instables, et fréquemment encodés dans des formats qui ne peuvent être traités que lorsque le fichier est entièrement intact.
Comment Tus change la donne
Tus repense le téléversement comme une conversation avec état plutôt que comme une livraison en une seule fois. Au lieu d'envoyer un fichier en un flux continu d'octets, le client divise la charge utile en morceaux. Plus important encore, le serveur se souvient de l'offset, le nombre exact d'octets qu'il a reçus jusqu'à présent. Cette persistance de l'état est ce qui rend la reprise possible. Le protocole est intentionnellement simple. Il ne nécessite ni WebSockets, ni gRPC, ni SDK propriétaires. Il utilise les méthodes HTTP que vous connaissez déjà.
Les trois requêtes qui permettent la reprise
Chaque téléversement tus suit une danse prévisible.
D'abord, le client envoie une requête POST à un point de terminaison tus connu. Les en-têtes décrivent le fichier. L'en-tête Upload-Length indique la taille finale en octets, et les métadonnées optionnelles telles que le nom du fichier ou le type de contenu transitent dans l'en-tête Upload-Metadata sous la forme d'une liste de paires clé-valeur encodées en base64 et séparées par des virgules. Le serveur crée une ressource de téléversement vide et répond avec un statut 201 Created accompagné d'un en-tête Location pointant vers une URL unique. Cette URL est l'adresse du téléversement pour le reste de sa vie.
Vient ensuite la requête PATCH. Le client envoie des morceaux de données binaires brutes à cette URL unique. Deux en-têtes critiques accompagnent la charge utile. Content-Type doit être application/offset+octet-stream, et Upload-Offset doit correspondre à la position en octets où ce morceau commence. Le serveur vérifie que l'offset correspond à ses propres enregistrements. Si ce n'est pas le cas, le serveur renvoie un 409 Conflict, protégeant ainsi contre un état corrompu. Si tout concorde, le serveur ajoute les octets, met à jour son offset interne et renvoie une réponse 204 No Content accompagnée du nouvel Upload-Offset. La taille des morceaux est configurable, mais la pratique courante se situe entre quelques centaines de kilo-octets et quelques mégaoctets. Des morceaux plus petits génèrent plus de surcharge HTTP mais permettent de se rétablir plus rapidement des erreurs. Des morceaux plus grands réduisent le nombre d'allers-retours mais gaspillent plus de bande passante en cas d'échec en plein milieu du transfert.
Enfin, la requête HEAD. C'est le filet de sécurité. Si un PATCH échoue au milieu d'un morceau, par exemple après trois mégaoctets d'une tranche de cinq mégaoctets, la connexion est coupée. Lorsque le client retrouve l'accès au réseau, il envoie une requête HEAD à l'URL de téléversement. Le serveur répond avec l'Upload-Offset actuel. Le client compare