Pourquoi mon navigateur Web n'arrive-t-il parfois pas à afficher les temps de téléchargement restants?

Table des matières:

Pourquoi mon navigateur Web n'arrive-t-il parfois pas à afficher les temps de téléchargement restants?
Pourquoi mon navigateur Web n'arrive-t-il parfois pas à afficher les temps de téléchargement restants?

Vidéo: Pourquoi mon navigateur Web n'arrive-t-il parfois pas à afficher les temps de téléchargement restants?

Vidéo: Pourquoi mon navigateur Web n'arrive-t-il parfois pas à afficher les temps de téléchargement restants?
Vidéo: Les 10 ASTUCES INCONTOURNABLES sur CHROMEBOOK - YouTube 2024, Mars
Anonim
Parfois, l'indicateur de progression de téléchargement sur votre navigateur (ou une autre application) jette simplement les mains en l'air et renonce à afficher le temps de téléchargement restant. Pourquoi parvient-il parfois à fixer la durée de téléchargement projetée et parfois à ne pas tout rapporter?
Parfois, l'indicateur de progression de téléchargement sur votre navigateur (ou une autre application) jette simplement les mains en l'air et renonce à afficher le temps de téléchargement restant. Pourquoi parvient-il parfois à fixer la durée de téléchargement projetée et parfois à ne pas tout rapporter?

La séance de questions et réponses d’aujourd’hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté.

La question

Le lecteur superutilisateur Coldblackice veut savoir pourquoi son navigateur ne nettoie pas toujours la saleté:

Occasionally, when downloading a file in a web browser, the download progress doesn’t “know” the total size of the file, or how far along in the download it is - it just shows the speed at which it’s downloading, with a total as “Unknown”.

Why wouldn’t the browser know the final size of some files? Where does it get this information in the first place?

Où en effet?

Les réponses

Gronostaj, contributeur à SuperUser, offre les informations suivantes:

To request documents from web servers, browsers use the HTTP protocol. You may know that name from your address bar (it may be hidden now, but when you click the address bar, copy the URL and paste it in some text editor, you’ll see

https://

au début). C’est un protocole simple basé sur du texte et qui fonctionne comme ceci:

Tout d’abord, votre navigateur se connecte au serveur du site Web et envoie l’URL du document qu’il souhaite télécharger (les pages Web sont également des documents), ainsi que des détails sur le navigateur lui-même (User-Agent, etc.). Par exemple, pour charger la page principale sur le site SuperUser,

https://superuser.com/

mon navigateur envoie une requête qui ressemble à ceci:

GET / HTTP/1.1 Host: superuser.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) Accept-Encoding: gzip,deflate,sdch Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: [removed for security] DNT: 1 If-Modified-Since: Tue, 09 Jul 2013 07:14:17 GMT

La première ligne spécifie le document que le serveur doit renvoyer. Les autres lignes sont appelées en-têtes; ils ressemblent à ceci:

Header name: Header value

Ces lignes envoient des informations supplémentaires qui aident le serveur à décider quoi faire.

Si tout va bien, le serveur répondra en envoyant le document demandé. La réponse commence par un message d’état, suivi de quelques en-têtes (avec des détails sur le document) et enfin, si tout va bien, du contenu du document. Voici à quoi ressemble la réponse du serveur SuperUser à ma requête:

HTTP/1.1 200 OK Cache-Control: public, max-age=60 Content-Type: text/html; charset=utf-8 Expires: Tue, 09 Jul 2013 07:27:20 GMT Last-Modified: Tue, 09 Jul 2013 07:26:20 GMT Vary: * X-Frame-Options: SAMEORIGIN Date: Tue, 09 Jul 2013 07:26:19 GMT Content-Length: 139672 […snip…]

Après la dernière ligne, le serveur de SuperUser ferme la connexion.

La première ligne (

HTTP/1.1 200 OK

) contient le code de réponse, dans ce cas il est

200 OK

. Cela signifie que le serveur retournera un document, comme demandé. Lorsque le serveur ne parvient pas à le faire, le code sera différent: vous avez probablement déjà vu

404 Not Found

et

403 Forbidden

est assez commun, aussi. Ensuite, les en-têtes suivent.

Lorsque le navigateur trouve une ligne vide dans la réponse, il sait que tout ce qui se trouve au-delà de cette ligne correspond au contenu du document demandé. Donc dans ce cas

est la première ligne du code de la page d’accueil du superutilisateur. Si je demandais un document à télécharger, il s'agirait probablement de caractères charabia, car la plupart des formats de document sont illisibles sans traitement préalable.

Retour aux en-têtes. Le plus intéressant pour nous est le dernier,

Content-Length

. Il indique au navigateur le nombre d'octets de données auxquels il doit s'attendre après la ligne vide. Il s'agit donc en gros de la taille du document exprimée en octets. Cet en-tête n’est pas obligatoire et peut être omis par le serveur. Parfois, la taille du document ne peut pas être prédite (par exemple lorsque le document est généré à la volée), parfois les programmeurs fainéants ne l'incluent pas (assez commun sur les sites de téléchargement de pilotes), parfois les sites Web sont créés par des débutants qui ne savent pas d'un tel en-tête.

Quoi qu'il en soit, quelle qu'en soit la raison, l'en-tête peut être manquant. Dans ce cas, le navigateur ne sait pas quelle quantité de données le serveur va envoyer et affiche donc la taille du document comme suit.inconnu, en attente de la fermeture de la connexion par le serveur. Et c’est la raison des tailles de document inconnues.

Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.

Conseillé: