01. Reconstituer le trajet HTTP

Comprendre le mécanisme

HTTP organise un échange de requêtes et de réponses. Dans une architecture réelle, le navigateur peut parler à un CDN, qui contacte un reverse proxy puis une application. Chaque intermédiaire possède son propre cache, ses limites et sa journalisation. Le serveur indiqué par un en-tête ne décrit donc pas à lui seul toute la chaîne. Une connexion TLS et une session applicative sont aussi des états différents : la première protège un canal, la seconde établit une continuité d’identité selon une politique.

Raisonner et vérifier

Pour diagnostiquer, séparez observation et déduction. Une erreur reçue dans le navigateur peut être fabriquée avant le framework. Relevez méthode, URL, statut, horodatage, identifiant de corrélation et couche ayant journalisé la requête. Le corps multipart affiché dans un outil de développement peut omettre les octets binaires ; la taille de la réponse n’est pas celle de l’upload. Comparez les indices sur le même trajet plutôt que modifier une limite au hasard.

Refus avant le framework

Un proxy peut refuser avant PHP. Plusieurs couches peuvent produire une réponse avant le framework. Une limite de corps peut interrompre le transfert au reverse proxy. Cherchez d’abord si PHP a reçu la demande ; modifier le contrôleur ne corrige pas une décision prise avant son exécution.

Localiser un 413

Une réponse 413 peut être émise par nginx. Le statut seul ne désigne pas un contrôle de formulaire. Le champ Server est un indice sur la couche qui répond, pas une cartographie complète. Corrélez le statut avec les journaux nginx et application pour attribuer le refus sans déduire toute l’architecture d’un seul header.

Longueur de réponse

Content-Length de réponse décrit cette réponse. Requête et réponse sont deux messages distincts. Content-Length: 176 dans la réponse décrit sa propre longueur de corps annoncée. Cela ne mesure ni le fichier ZIP envoyé ni les octets décompressés ; relevez séparément les deux messages.

Canal et identité

TLS et session applicative ont des cycles distincts. Le canal et l’identité applicative sont des états différents. Une nouvelle connexion TLS peut porter la même session applicative via un cookie. Inversement, un canal existant peut transporter des demandes pour lesquelles l’utilisateur se déconnecte ; les deux cycles ne se confondent pas.

Corrélation

Une corrélation aide à rapprocher les journaux. Relier des événements ne prouve pas une identité. Utilisez un identifiant non sensible pour rapprocher événements proxy et application. Contrôlez sa génération et sa validation afin qu’une entrée client ne crée pas un contexte de diagnostic trompeur.

Cartographier les sauts

Le trajet peut inclure un CDN et un proxy. Un champ ne décrit pas tous les intermédiaires. Dessinez navigateur, CDN, proxy, serveur web et runtime. Pour chaque saut, notez protocole et terminaison TLS ; cette vue explique pourquoi une limite ou un cache intermédiaire peut décider avant l’origine.

Enveloppe multipart

Le formulaire multipart ajoute des octets au fichier. Séparateurs et champs participent à la taille transmise. Les séparateurs, en-têtes de parties et champs CSRF ajoutent de la taille au fichier. Prévoyez une marge explicite et mesurez la requête complète plutôt que déduire sa taille du seul explorateur de fichiers.

Non-effet précoce

Une requête peut échouer avant toute écriture métier. Le point de refus détermine les traitements atteints. Un refus avant l’application ne devrait produire aucune écriture métier. Vérifiez base et stockage d’import dans un test de laboratoire ; l’absence de page applicative n’exclut pas à elle seule tout traitement partiel.

Chronologie

Comparer les heures exige une chronologie cohérente. Les observations doivent concerner le même échange. Les horloges et fuseaux des composants doivent permettre une comparaison cohérente. Préférez un format partagé et une corrélation stable, puis vérifiez la dérive avant d’attribuer un événement à la mauvaise tentative.

Observation navigateur

Une capture navigateur constitue une observation partielle. Chaque outil observe une portion du trajet. Les outils peuvent masquer les octets binaires ou agréger certaines informations. Conservez les faits observés et complétez avec mesures serveur ; un champ vide affiché ne prouve pas que le fichier n’a pas été transmis.

Atelier guidé : lire, expliquer et vérifier le code

HTTP/1.1 413 Content Too Large
Server: nginx
Content-Type: text/html
Content-Length: 176

[corps de réponse HTML omis]

La réponse montre un 413 et un petit corps HTML annoncé de 176 octets. Aucune de ces lignes ne donne la taille du ZIP envoyé. Relevez séparément taille de fichier, taille totale multipart et limite du saut qui refuse, puis confrontez les journaux de ce saut aux traces applicatives.

Le champ appartient à la réponse observée. La requête possède sa propre taille. Aucune extraction n’est mesurée ici. Cette limite n’est pas portée par ce champ.

Travail pratique : Dessinez votre chaîne de laboratoire et attribuez à chaque étape une limite de corps, un budget de temps et un journal. Simulez un refus au proxy.

Critères de correction : Envoyez deux fichiers de tailles connues vers un endpoint de test, puis confrontez les journaux proxy et application. Vérifiez qu’un refus précoce ne déclenche aucune écriture métier. Notez les tailles de requête et de réponse séparément.