Waarom geeft mijn webbrowser soms resterende downloadtijden niet weer?

Soms gooit de trouwe download-voortgangsmeter in uw browser( of een andere applicatie) gewoon zijn handen in de lucht en geeft hij de resterende downloadtijd op. Waarom spijkert het soms de geprojecteerde downloadtijd op en rapporteert het soms niet allemaal samen?

De vraag van vandaag &Antwoord sessie komt naar ons met dank aan SuperUser-een onderverdeling van Stack Exchange, een community-gestuurde groepering van Q & A-websites.

De vraag

SuperUser-lezer Coldblackice wil weten waarom zijn browser niet altijd voor de gek houdt:

Soms, wanneer een bestand in een webbrowser wordt gedownload, "weet" de download niet de totale grootte van het bestand, ofhoever in de download het is - het laat alleen de snelheid zien waarmee het downloadt, met een totaal als "onbekend".

Waarom zou de browser de uiteindelijke grootte van sommige bestanden niet weten? Waar haalt het deze informatie in de eerste plaats vandaan?

Waar inderdaad?

De antwoorden

SuperUser-bijdrager Gronostaj biedt het volgende inzicht:

Om documenten aan te vragen bij webservers, gebruiken browsers het HTTP-protocol. Misschien kent u die naam van uw adresbalk( deze kan nu verborgen zijn, maar als u op de adresbalk klikt, kopieert u de URL en plakt u deze in een teksteditor, dan ziet u http: // aan het begin).Het is een eenvoudig op tekst gebaseerd protocol en het werkt als volgt:

Eerst maakt uw browser verbinding met de server van de website en verzendt hij een URL van het document dat hij wil downloaden( webpagina's zijn ook documenten) en enkele details over de browser zelf( User-Agent, enz.).Als u bijvoorbeeld de hoofdpagina op de SuperUser-site wilt laden, http: //superuser.com/, verzendt mijn browser een aanvraag die er als volgt uitziet:

GET / HTTP / 1.1 Host: superuser.com Verbinding: keep-alive Accepteer: 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-Taal: pl-PL, pl; q = 0.8, en-US; q = 0.6, en; q = 0.4 Cookie: [verwijderd voor beveiliging] DNT: 1 If-Modified-Since: Tue, 09 Jul 2013 07:14:17 GMT

De eersteregel geeft aan welk document de server moet retourneren. De andere regels worden kopteksten genoemd;ze zien er zo uit:

Headernaam: Header-waarde

Deze regels verzenden aanvullende informatie die de server helpt te beslissen wat te doen.

Als alles goed is, reageert de server door het gevraagde document te verzenden. Het antwoord begint met een statusbericht, gevolgd door een aantal kopteksten( met details over het document) en tot slot, als alles goed gaat, de inhoud van het document. Dit is wat het antwoord van de SuperUser-server op mijn verzoek ziet:

HTTP / 1.1 200 OK Cache-Control: public, max-age = 60 Content-Type: text / html;charset = utf-8 Verloopt: di, 09 jul 2013 07:27:20 GMT Laatst gewijzigd: di, 09 jul 2013 07:26:20 GMT variëren: * X-frame-opties: SAMEORIGIN Datum: di, 09 jul 201307:26:19 GMT Content-Length: 139672 & lt;! DOCTYPE html & gt;& Lt; html & gt;[... knip. ..] & lt; / html & gt;

Na de laatste regel sluit de server van SuperUser de verbinding.

De eerste regel( HTTP / 1.1 200 OK) bevat de reactiecode, in dit geval is het 200 OK.Dit betekent dat de server een document retourneert, zoals gevraagd. Wanneer de server dit niet lukt, is de code iets anders: je hebt waarschijnlijk 404 Not Found gezien en 403 Forbidden is ook heel gewoon. Dan volgen de headers.

Wanneer de browser een lege regel in het antwoord vindt, weet het dat alles voorbij die regel de inhoud is van het document waar het om heeft gevraagd. Dus in dit geval & lt;! DOCTYPE html & gt;is de eerste regel van de homepage van de SuperUser. Als ik een document zou vragen om te downloaden, zou het waarschijnlijk een paar wuftekens zijn, omdat de meeste documentindelingen onleesbaar zijn zonder voorafgaande verwerking.

Terug naar headers. De meest interessante voor ons is de laatste, inhoud-lengte. Het laat de browser weten hoeveel bytes gegevens het na de lege regel mag verwachten, dus eigenlijk is het de documentgrootte uitgedrukt in bytes. Deze header is niet verplicht en kan door de server worden weggelaten. Soms kan de documentgrootte niet worden voorspeld( bijvoorbeeld wanneer het document on the fly wordt gegenereerd), soms bevatten luie programmeurs dit niet( vrij vaak op downloadsites van stuurprogramma's), soms worden websites gemaakt door nieuwkomers die niet wetenvan een dergelijke header.

Hoe dan ook, wat de reden ook is, de kop mag ontbreken. In dat geval weet de browser niet hoeveel gegevens de server gaat verzenden en wordt dus de documentgrootte weergegeven als onbekend , wachtend tot de server de verbinding heeft verbroken. En dat is de reden voor onbekende documentgroottes.

Heeft u iets toe te voegen aan de uitleg? Geluid uit in de opmerkingen. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk de volledige discussiethread hier.