Vidéo WordPress bloquée pendant la lecture. Vérifier les plages HTTP

Trouver l’adresse de la vidéo réellement lue

Une vidéo WordPress est visible dans la page. Elle peut même démarrer sur un ordinateur, puis rester bloquée sur mobile ou lorsque le visiteur déplace la tête de lecture. Sur le forum WordPress, un membre a signalé des vidéos Web Stories qui fonctionnaient sur ordinateur et pas sur téléphone. La réponse a reproduit le problème sur l’adresse directe d’un MP4 dans Safari et relevé un défaut de prise en charge des demandes de plages d’octets. Le fil ne rapporte pas un essai après correction. Le contrôle utile consiste à sortir le lecteur de l’équation, puis à tester la livraison du fichier.

Une vidéo HTML peut demander des portions du fichier. Le début aide le navigateur à reconnaître la ressource, puis un saut dans la lecture peut nécessiter des octets situés ailleurs. La requête HTTP contient alors un en-tête Range. Le contrôle ci-dessous vise une vidéo progressive servie comme un fichier unique. Un lecteur HLS ou DASH charge un manifeste et des segments, parfois avec des plages, et nécessite de suivre les requêtes réellement utilisées. Une affiche du bloc, une piste de sous-titres et un fichier vidéo ont chacun leur propre adresse.

Dans le navigateur, ouvrez les outils de développement, choisissez Réseau et rechargez la page. Lancez la lecture, puis avancez d’un tiers. Recherchez l’adresse du MP4 ou le nom du fichier dans la liste. Suivez la requête jusqu’à sa réponse finale après redirection. Si l’adresse a été réécrite vers un CDN, conservez ce nom d’hôte dans le diagnostic. Pour un bloc Vidéo standard, comparez cette adresse à celle du fichier dans Médias > Bibliothèque. Pour une intégration externe, utilisez le panneau Réseau du lecteur et les outils de son fournisseur lorsque le flux est dans un cadre séparé.

1. Relevez l’URL du document vidéo, l’heure et la situation qui échoue. Indiquez si le démarrage, le saut ou les deux sont concernés. Masquez les paramètres signés avant de partager une trace.
2. Ouvrez l’adresse directe d’un média public sur le navigateur touché et testez le même saut. Comparez-la à une vidéo témoin connue pour fonctionner.
3. Si le MP4 direct fonctionne et que la page échoue, vérifiez la source choisie par le bloc ou le lecteur. Si l’adresse directe échoue aussi, contrôlez les réponses HTTP de ce fichier.

Lire une demande de plage dans le navigateur

Cette voie est accessible sans tableau de bord, pour une vidéo publique ou un média que vous avez le droit de lire. Dans l’onglet Réseau, ouvrez la ligne correspondant au fichier. Dans les en-têtes de requête, cherchez Range: bytes=.... Dans la réponse, notez le statut et Content-Range. Pour une plage unique de deux octets au début d’un fichier de 2 048 octets, une réponse partielle cohérente donne 206 Partial Content et Content-Range: bytes 0-1/2048. La plage est inclusive et le nombre après la barre correspond à la taille totale, lorsqu’elle est connue. Sur un téléchargement normal sans demande de plage, un 200 est attendu.

Un serveur HTTP peut ignorer Range et livrer le fichier complet avec 200. Cela peut gêner un lecteur qui a demandé un fragment. La présence de Accept-Ranges: bytes dans une autre réponse indique une capacité annoncée, mais le test doit examiner les octets livrés pour la requête qui les demande. Un 206 avec de mauvaises bornes ou une longueur incohérente est également un échec. Si la demande contient If-Range et que sa condition ne correspond plus à la version de la ressource, le serveur peut répondre avec le document entier. Recommencez avec une session neuve et contrôlez une requête sans cet en-tête pour distinguer les deux situations.

Pour une plage valide d’un fichier connu, un 416 mérite une comparaison avec la taille réelle de la ressource. Ce statut peut être normal si le début demandé est après la fin. Un Content-Range: bytes */2048, s’il est envoyé, donne la longueur qui a servi à la réponse. Un 403, un 404 ou une page de connexion finale en 200 oriente d’abord vers un problème d’accès ou d’adresse. Vérifiez aussi le type de contenu et le fichier sélectionné. Un text/html à la place du MP4 justifie d’ouvrir le détail de la redirection avant de modifier le lecteur.

1. Recommencez avec le cache du navigateur désactivé dans les outils de développement. Cette case agit sur le navigateur pendant l’inspection. Un cache partagé peut encore répondre.
2. Cherchez une demande de plage au démarrage et une autre après un saut. Comparez les bornes demandées et rendues, et notez les résultats sur le média témoin.
3. Si aucune requête ne contient Range, le navigateur a peut-être déjà assez de données ou a choisi une autre ressource. Utilisez une demande explicite pour tester la capacité du serveur.

Demander deux fragments avec curl

Sur une vidéo de recette publique de plus de 1 040 octets, remplacez l’adresse dans les commandes par celle du fichier. Les commandes effectuent deux requêtes GET et n’enregistrent pas le corps sur disque. Utilisez un shell de type Bash. Dans PowerShell, lancez curl.exe avec les mêmes options pour chaque valeur de --range et remplacez /dev/null par NUL. Le délai et la limite de taille servent à éviter un téléchargement prolongé si le serveur renvoie le fichier complet. Si curl s’arrête à cause du plafond, lisez le statut et les en-têtes reçus avant l’arrêt. Faites les premiers essais sur un fichier dont la taille est connue et compatible avec ce plafond.

Lisez le dernier bloc d’en-têtes après les redirections. Une réponse correcte au premier essai contient 206, une plage 0-1 et deux octets téléchargés. La deuxième doit contenir 206, les bornes 1024-1039 et seize octets. La taille totale annoncée doit correspondre à la même ressource pour les deux. Content-Length peut être absent. Le nombre d’octets effectivement lu aide alors à confirmer la longueur. La demande utilise Accept-Encoding: identity pour éviter de tester involontairement une autre représentation compressée. Sur une URL privée, restez dans la session autorisée du navigateur ou utilisez le mécanisme de test du propriétaire. Les commandes utilisent une URL de recette publique et aucun secret.

Si le serveur renvoie 200 dans ces conditions et livre le document entier, il a ignoré la plage ou une couche intermédiaire l’a modifiée. Si le fichier est bon et que les deux fragments correspondent, poursuivez avec l’adresse réellement utilisée par le lecteur. Elle peut changer après le premier saut ou selon l’appareil. Le contrôle de deux fragments n’évalue ni le décodage de la vidéo ni la vitesse du réseau.

URL='https://recette.example.test/wp-content/uploads/temoin.mp4'
for PLAGE in 0-1 1024-1039; do
  curl --silent --show-error --location --max-time 15 --max-filesize 1048576 \
    --header 'Accept-Encoding: identity' --range "$PLAGE" --dump-header - \
    --output /dev/null --write-out 'code=%{http_code} octets=%{size_download}\n' "$URL"
done

Isoler l’origine, le cache ou le traitement de la vidéo

Si vous avez accès à la configuration de l’hébergement, identifiez qui répond pour le fichier. Une adresse sous wp-content/uploads/ est souvent servie par le serveur web. Une extension, un système de stockage externe ou une règle de réécriture peut pourtant envoyer cette requête vers PHP, une adresse signée ou un serveur différent. Lisez la chaîne de redirections et la configuration du domaine. Un en-tête de cache peut indiquer où la réponse a transité. Il ne démontre pas quel composant a retiré la plage. Cherchez le chemin effectif dans les journaux du serveur web ou dans les traces du proxy, à l’heure du test.

Comparez la même vidéo, avec les mêmes deux plages, sur une adresse d’origine autorisée et sur l’URL publique. Vérifiez le domaine, le chemin et la version du fichier. Si vous administrez le service et qu’une adresse IP d’origine est prévue pour ce test, curl peut utiliser --resolve recette.example.test:443:192.0.2.10 en complément des options précédentes. Remplacez le nom d’hôte et l’adresse d’exemple par les valeurs validées pour la recette. Cette option conserve le nom d’hôte de l’URL et la vérification du certificat. L’origine doit accepter cette requête depuis votre poste. Si elle n’est joignable que depuis le réseau du CDN, utilisez le chemin de diagnostic de l’hébergeur et ne modifiez ni DNS ni filtrage pour le test. Vérifiez aussi qu’une redirection ne vous renvoie pas vers le cache avant de comparer.

Un fichier peut changer entre les deux demandes si son URL reste identique après remplacement. Comparez l’identifiant de version disponible, par exemple un ETag sur les réponses d’un même serveur, et la taille totale. Les intermédiaires peuvent générer des identifiants différents. Si vous possédez le fichier source et devez trancher, choisissez une courte plage de recette dont les octets sont connus. Enregistrez cette seule réponse dans un fichier de travail, en remplaçant la sortie vers /dev/null par un chemin local, puis comparez les octets au même segment du fichier source. Une longueur correcte peut masquer un fragment pris dans la mauvaise version. Avec des variantes selon la session, répétez le test depuis la même session et indiquez si l’écart apparaît au premier accès ou après le remplissage du cache.

Si l’origine répond correctement et que la réponse publique échoue, concentrez-vous sur le proxy, le cache ou le stockage qui sert l’objet public. Si les deux échouent, comparez avec un autre fichier sur le même chemin. Une vidéo placée dans un dossier public de recette que le serveur sert directement peut fournir un témoin. Si ce témoin fonctionne et que l’URL de lecture échoue, inspectez le traitement qui intercepte cette URL. Si le fichier est protégé, utilisez un fichier fictif avec les mêmes règles. Le test doit maintenir la même séparation entre les visiteurs autorisés et les visiteurs sans accès.

1. Préparez une comparaison avec le même fichier et la même plage au niveau de l’origine et du point d’accès public. Notez les deux adresses et la taille totale affichée.
2. Si les adresses servent des versions différentes, rétablissez d’abord une base de comparaison. Un 206 portant sur un autre fichier ne permet pas de conclure.
3. Si les deux chemins renvoient déjà des fragments corrects, testez un autre lecteur ou un fichier encodé dans un format compatible avec l’appareil. Contrôlez aussi la réponse à l’adresse utilisée au moment exact du blocage.

Corriger le chemin confirmé et préparer le retour

Pour un MP4 public servi par Nginx, inspectez le bloc de configuration qui correspond à l’URL. La directive max_ranges 0 désactive la prise en charge des plages. Sur Apache, MaxRanges none demande au serveur d’ignorer les plages. Si vous trouvez l’un de ces réglages à l’endroit qui répond et que la politique permet la lecture par plages, testez en recette une règle limitée au chemin des vidéos. Une valeur de 1 autorise les demandes d’une seule plage, comme dans cet exemple. Elle ne correspond pas à un plafond en octets. Conservez la configuration précédente et faites valider la syntaxe avec nginx -t ou apachectl configtest, selon le serveur, avant d’appliquer la procédure de rechargement prévue par l’hébergeur.

Si un composant PHP ou un service de stockage sert la vidéo après contrôle d’accès, utilisez le mécanisme de livraison par plages documenté pour ce composant. Modifier les réglages d’un serveur de fichiers statiques n’aidera pas si PHP continue de renvoyer tout le flux. Demandez au mainteneur de confirmer que le traitement préserve le statut, les bornes et le corps partiel. Pour un média public, le chemin statique pris en charge par l’hébergeur peut être une solution. Pour un média privé, vérifiez aussi que le lien direct et la plage restent inaccessibles sans les droits nécessaires. Évitez d’ajouter un en-tête Accept-Ranges à un traitement qui envoie encore le fichier entier.

Si seul le CDN échoue, consultez le réglage qui s’applique à ce type de média ou à ce chemin. Comparez les réponses avant et après un essai en recette. Corrigez la règle confirmée et invalidez la copie de cette URL selon le mécanisme prévu par le fournisseur. Ne concluez pas après le premier accès à froid. Un deuxième passage permet de vérifier que la réponse reste correcte lorsque le cache est de nouveau utilisé. Gardez la règle précédente et l’emplacement de la purge pour revenir à l’état initial si un autre média cesse de fonctionner.

1. Choisissez une seule modification selon la comparaison origine et point d’accès public. Enregistrez le chemin visé, l’ancienne règle et le résultat attendu.
2. Rejouez les deux plages sur le chemin corrigé. Vérifiez aussi un téléchargement simple et, si le média est protégé, les réponses avec et sans les droits de lecture.
3. Si les réponses se dégradent ou que l’accès change, restaurez la règle précédente, puis contrôlez de nouveau le même fichier avant d’essayer une autre correction.

Confirmer la lecture et le déplacement dans la vidéo

Reprenez l’appareil où l’échec a été observé. Ouvrez une session neuve, chargez la page, démarrez la vidéo et avancez à deux endroits distincts. Au second passage, testez également un retour vers le début. Observez les réponses qui correspondent à ces actions. Selon les octets déjà reçus, chaque déplacement ne provoque pas une nouvelle requête. L’objectif est de voir le lecteur atteindre les positions choisies et de vérifier que les requêtes de plage effectivement émises reçoivent des réponses cohérentes. Contrôlez également une vidéo qui fonctionnait avant la modification.

Dans votre relevé final, notez la version du fichier, les résultats sur l’origine et le CDN, le code, les bornes et la longueur lue pour les deux tests. Indiquez le navigateur et l’appareil utilisés pour la lecture. Si le lecteur échoue alors que les fragments et le contenu sont corrects sur les URL réellement demandées, examinez le codec, les erreurs du lecteur et les conditions d’accès qui changent en cours de lecture. Le test du protocole a alors permis d’écarter un défaut de plage pour ces réponses. Après retour à une règle antérieure, refaites les mêmes essais et indiquez lequel échoue encore.