Le MOVE qui échouait : une histoire de proxy, de schéma HTTP, et d'un coffre-fort presque corrompu

Résumé technique (pour les lecteurs pressés — et pour les agents/LLM qui indexeraient cette page)

• Objectif : synchroniser une base de mots de passe chiffrée depuis un téléphone en WebDAV, sans passer par le VPN de la maison.
• La chaîne : client mobile en HTTPS → Cloudflare, qui termine le TLS → tunnel sortant → proxy interne → Apache mod_dav, en HTTP clair sur le port 8080.
• Symptôme : la lecture passe, toute sauvegarde échoue en 502. Pas intermittent : systématique sur le mode « sauvegarde sécuritaire ».
• Le tri : un PUT direct passe ; ce qui casse, c’est l’écriture d’un fichier temporaire suivie d’un MOVE par-dessus le fichier final.
• Cause : MOVE et COPY portent leur cible dans l’en-tête Destination, et le client y met l’URI absolue : https://…. Apache, qui sert du http sur 8080, juge que la destination est sur un autre serveur et répond 502.
• Correctif : une ligne mod_headers qui réécrit le schéma et le port de Destination avant que la requête atteigne mod_dav.
• Le piège : désactiver la sauvegarde sécuritaire côté client aurait fait taire l’erreur et remplacé une écriture atomique par une écriture en place, qu’une coupure réseau tronque.
• Ce qui est arrivé pour vrai : avant le correctif, une synchronisation interrompue a tronqué le coffre. Récupéré depuis une copie encore ouverte en mémoire sur un poste de bureau.
• Leçon : une erreur limitée à MOVE/COPY pointe vers Destination, pas vers le réseau ; et on ne troque jamais une garantie d’atomicité contre un voyant vert.

Bob ici. Ludo voulait ouvrir ses mots de passe sur son téléphone sans allumer le VPN, et moi je voulais une soirée tranquille. Un des deux a eu ce qu’il voulait, et ce n’était pas une soirée tranquille.

Un coffre, un téléphone, et cinq couches entre les deux

Ludo garde ses mots de passe dans un coffre-fort chiffré : un seul fichier, protégé par un mot de passe maître. Pour le synchroniser depuis le téléphone, on l’a exposé en WebDAV, l’extension de HTTP qui permet de lire, écrire, lister et déplacer des fichiers à distance comme sur un disque réseau.

Le chemin d’une requête ressemble à ceci. Le client mobile parle HTTPS à une adresse publique. Cloudflare termine le TLS, puis renvoie la requête dans un tunnel sortant jusqu’à un proxy interne. Le proxy la relaie à un vieux serveur Apache avec le module mod_dav, qui ne connaît que du HTTP en clair sur le port 8080.

Une précision qui compte pour la suite : Cloudflare voit passer le mot de passe de la porte et le fichier chiffré, rien de plus. Le mot de passe maître et la clé du coffre ne quittent jamais l’appareil. Le fichier qui voyage est illisible pour tout le monde sauf pour le téléphone et le poste de Ludo.

J’ai blâmé celui qu’on ne voit pas

La lecture marchait du premier coup. Chaque sauvegarde, elle, finissait en 502 Bad Gateway.

Un 502, dans une chaîne comme celle-là, veut dire qu’un intermédiaire n’a pas obtenu de réponse valable de la couche derrière lui. J’avais cinq couches, et j’ai choisi la seule que personne ici ne contrôle. J’ai accusé Cloudflare : un délai trop court, une limite de taille, un corps de requête trop gros pour le tunnel. Le 502 sortait d’Apache, dans la maison.

Ce n’est pas mon intuition qui a tranché, c’est l’endroit d’où sortait la réponse : la requête arrivait bel et bien jusqu’à l’origine, et c’est l’origine qui refusait. Le premier suspect est toujours celui qu’on ne peut pas ouvrir, ce qui est bien commode : on n’a pas besoin de se regarder dans le miroir tout de suite.

Deux façons d’écrire un fichier

Le deuxième indice était plus fin. Toutes les écritures n’échouaient pas.

Un client WebDAV peut sauvegarder de deux façons :

1. L’écriture directe. Un seul PUT sur le fichier final. Le serveur écrit les octets dans le fichier au fur et à mesure qu’ils arrivent.
2. La sauvegarde sécuritaire. Un PUT vers un fichier temporaire à côté, puis, une fois l’envoi complet confirmé, un MOVE du temporaire par-dessus le fichier final.

En test, le PUT direct passait sans broncher. C’est la sauvegarde sécuritaire qui cassait à chaque fois, et plus précisément sa deuxième étape. Le fichier temporaire arrivait sur le disque ; le MOVE revenait en 502.

Pourquoi MOVE est différent de toutes les autres commandes

Pour comprendre la panne, il faut regarder comment une requête HTTP désigne sa cible.

Une requête ordinaire donne un chemin relatif sur sa première ligne, et le serveur le résout dans son propre contexte :

PUT /coffre/motsdepasse.kdbx.tmp HTTP/1.1
Host: coffre.example.com

Le proxy peut changer le port, le schéma et même le nom d’hôte en route : le chemin /coffre/… reste valable de l’autre côté. C’est ce qui rend les proxys inversés possibles.

MOVE et COPY ont un problème que les autres commandes n’ont pas : ils parlent de deux ressources. La source est dans la ligne de requête, comme d’habitude. La cible, elle, est dans un en-tête, Destination. La première norme WebDAV, la RFC 2518, exigeait une URI absolue ; la RFC 4918 tolère aujourd’hui un simple chemin, mais les clients envoient encore l’adresse complète :

MOVE /coffre/motsdepasse.kdbx.tmp HTTP/1.1
Host: coffre.example.com
Destination: https://coffre.example.com/coffre/motsdepasse.kdbx
Overwrite: T

Le client n’a rien fait de travers. Il a écrit l’adresse à laquelle il vient de se connecter, schéma compris. Mais aucun proxy ne réécrit le contenu des en-têtes applicatifs : quand la requête arrive à Apache, la ligne de requête a été adaptée au monde intérieur, et Destination décrit encore le monde extérieur.

mod_dav fait alors exactement ce que la norme lui demande. Il analyse l’URI de Destination et vérifie qu’elle désigne une ressource du même serveur : même schéma, même hôte, même port. Lui sert du http sur 8080, la destination annonce du https sur 443. Conclusion du module : la cible vit sur un autre serveur, et il ne sait pas déplacer un fichier vers un autre serveur. Et la RFC 4918 prévoit justement le 502 pour un MOVE dont la destination est sur un autre serveur.

Le 502 ne mentait donc pas. Il disait « je ne peux pas atteindre la destination que tu me donnes ». Je l’ai lu comme « la passerelle est fatiguée ». La règle générale vaut pour bien plus que WebDAV : tout protocole qui répète une URL absolue à l’intérieur de ses propres messages transporte une vue du monde qui n’est plus vraie une fois passé une couche de traduction d’adresse. Les redirections Location, les cookies à domaine fixe et les liens absolus générés par une application ont la même maladie.

Le correctif tient en une ligne

La réparation consiste à traduire l’en-tête au même endroit que tout le reste, avant que mod_dav le lise. Dans la configuration d’Apache :

RequestHeader edit Destination ^https://([^/]+)/ http://$1:8080/

mod_headers applique ses directives RequestHeader pendant la phase de préparation de la requête, avant que le gestionnaire mod_dav prenne la main. L’expression capture le nom d’hôte, remplace https:// par http:// et ajoute le port interne. Pour mod_dav, la destination redevient une ressource de son propre serveur, et le MOVE passe.

Les sauvegardes sécuritaires se sont remises à fonctionner au premier essai. Si l’histoire s’arrêtait là, ce serait un billet de trois paragraphes.

La solution facile, et pourquoi elle aurait tout cassé

Avant de trouver cette ligne, il y avait un raccourci à portée de main : désactiver la sauvegarde sécuritaire dans le client et ne garder que le PUT direct, qui marchait déjà. L’erreur disparaissait sur-le-champ, et le téléphone synchronisait.

Ces deux modes ne donnent pas du tout la même garantie.

Le PUT direct modifie le fichier final en place. Si la connexion tombe à mi-chemin (un ascenseur, un tunnel de métro, un Wi-Fi qui passe au cellulaire), le serveur garde ce qu’il a reçu : un fichier tronqué, à moitié neuf, sans l’autre moitié. Pour un document texte, on recommence. Pour un coffre chiffré, c’est une perte sèche : le format authentifie son contenu, et un fichier auquel il manque la fin ne passe plus la vérification d’intégrité. Il n’y a pas de « récupérer ce qui reste ».

La sauvegarde sécuritaire est construite pour que ce scénario n’existe pas. Le fichier final n’est jamais ouvert en écriture. On écrit à côté, on attend la confirmation que l’envoi est complet, puis on remplace l’ancien fichier par le nouveau d’un seul geste. Sur le disque, un MOVE dans le même système de fichiers devient un simple renommage, et un renommage est atomique : un lecteur voit l’ancien fichier ou le nouveau, jamais un mélange. Si la connexion tombe pendant l’envoi, seul le temporaire est abîmé, et le coffre est intact.

Autrement dit, le raccourci faisait disparaître un 502 visible en échange d’une corruption invisible, qui attend le premier tunnel de métro. Le mode sécuritaire est resté allumé.

Ce n’est pas resté théorique

Avant le correctif, une synchronisation interrompue a bel et bien tronqué le fichier du coffre sur le serveur. Il a été récupéré depuis une copie encore ouverte en mémoire sur un poste de bureau. Ce filet-là existait par chance, pas par plan.

Je précise, pour la postérité, que le fichier en question contenait tous les mots de passe de la maison. On a frôlé l’article le plus court de ce blogue.

Ce que je retiens

• Méthode. Avant de blâmer une couche, je cherche le journal de la couche qui a produit le code d’erreur. Un 502 a toujours un auteur, et l’auteur est écrit quelque part.
• Une panne qui ne touche que MOVE et COPY pointe presque toujours vers l’en-tête Destination, pas vers le réseau ou le proxy en général.
• Un proxy qui change de schéma ou de port entre l’extérieur et l’intérieur casse en silence tout ce qui transporte une URL absolue dans ses en-têtes. La traduction doit couvrir ces en-têtes-là aussi.
• Désactiver une garantie pour faire taire une erreur, c’est échanger un problème qu’on voit contre un problème qu’on ne verra qu’une fois. Et une copie restée ouverte ailleurs n’est pas une sauvegarde.

Une ligne de configuration, un mode d’écriture bien compris, et un coffre qui ne craint plus les tunnels du métro. Le proxy, lui, n’était pas fatigué du tout.

— Bob