Pourquoi Firebug affiche-t-il une réponse "206 contenu partiel" à une demande de chargement de vidéo?
J'ai un tas d'éléments vidéo html5, avec leur attribut de précharge défini sur "auto". Ils commencent à charger correctement, mais je pense qu’il ya peut-être un problème de mise en cache, car chaque fois que je recharge la page (sans vider le cache), ils recommencent.
Lorsque j’ai vérifié le panneau Réseau dans firebug, j’ai remarqué que tout le reste (images et fichiers) me transmettait le message "304 non modifié" comme prévu, tandis que les fichiers vidéo (et audio) me transmettaient le message "206 contenus partiels", en entrées dupliquées.
La réponse "206 contenu partiel" apparaît également dans les entrées dupliquées lorsque la page est chargée avec le cache effacé, au lieu d'une réponse "200 OK", comme prévu.
Est-ce un comportement normal pour les éléments vidéo et audio? Si non, comment pourrait-il être corrigé?
Ce code de contenu partiel (206) peut est envoyé du serveur lorsque le client a demandé une plage (par exemple, "donnez-moi les 2 premiers Mo de données vidéo").
Il est essentiel pour le téléchargement de données en morceaux, ce qui évite de récupérer des ressources inutilisées. (Je regarde rarement une vidéo complète en ligne.) Regardez la demande sortante pour un en-tête Range.
Voir Codes d'état (RFC2616 - HTTP/1.1) (notez que tout code 2xx signifie "Succès"):
10.2.7 206 Contenu partiel:
Le serveur a satisfait à la demande partielle GET pour la ressource. La demande MUST a inclus un champ d'en-tête Range (section 14.35) indiquant la plage souhaitée , et PEUT avoir inclus un champ d'en-tête If-Range (section 14.27) pour effectuer la demande. conditionnel.
Et à partir de Range header section:
Si le serveur prend en charge l'en-tête Range et la ou les plages spécifiées sont appropriées pour l'entité.
- La présence d'un en-tête Range dans un GET inconditionnel modifie Ce qui est renvoyé si le GET réussit par ailleurs. Dans d’autres termes , la réponse porte un code d’état de 206 (Contenu partiel ) Au lieu de 200 (OK) .
Cependant, je ne comprends pas les complexités de la mise en cache et/ou des ETags ou de ce à quoi s'attendre dans FireFox.
Dans Firefox sur ma machine de développement locale, je ne pouvais pas lire de vidéos .webm à moins que le serveur ne soit configuré pour les utiliser. Firebug montrerait 206 mais rien ne montrerait. Cela peut être résolu en ajoutant
AddType video/webm .webm
à votre .htaccess.
Selon https://httpstatuses.com/206
"Un serveur NE DOIT PAS générer de réponse en plusieurs parties à une demande pour une seule plage, puisqu'un client qui ne demande pas plusieurs parties peut ne pas prendre en charge les réponses en plusieurs parties. Cependant, un serveur PEUT générer une charge utile multipart/byteranges avec une seule partie du corps si plusieurs plages ont été demandées et une seule plage a été jugée satisfaisable ou une seule plage est restée après la fusion. Un client qui ne peut pas traiter une réponse multipart/byteranges NE DOIT PAS générer une demande qui demande plusieurs plages.
Lorsqu'une charge utile de réponse en plusieurs parties est générée, le serveur DEVRAIT envoyer les parties dans le même ordre que celui dans lequel la spécification d'octets-plage correspondante est apparue dans le champ d'en-tête Plage reçu, à l'exclusion des plages jugées non satisfaisantes ou fusionnées dans d'autres plages. Un client qui reçoit une réponse en plusieurs parties DOIT inspecter le champ d'en-tête Content-Range présent dans chaque partie du corps afin de déterminer quelle plage est contenue dans cette partie du corps; un client ne peut pas compter sur la réception des mêmes plages qu’il a demandées, ni du même ordre qu’il a demandé. "