W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: Range Requests vs Content Codings

From: <K.Morgan@iaea.org>
Date: Sat, 21 Jun 2014 17:56:14 +0000
To: <zhong.j.yu@gmail.com>, <roland@zinks.de>
CC: <ietf-http-wg@w3.org>, <C.Brunhuber@iaea.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC201186DE992@sem002pd.sg.iaea.org>
Any Chrome/Chromium devs out there???

As we pointed out in [1], Chrome goes through a bit of a bizarre "song and dance" when it resumes interrupted transfers (not just for "downloads" of large entities by the way, also for static content such as css files and scripts - which also see a performance benefit from resumed downloading after an interruption, e.g. on a mobile network).

When resuming an interrupted transfer, Chrome actually sends two range requests. The first request Chrome sends asks for a single byte directly after the already downloaded portion and, if successful, sends a second request for the rest of the content by specifying the exact range. (See [1] for an example.)

Since Google is so finicky about saving RTTs, there must be a good reason for doing the 2-range-request "song and dance". There must be some Chrome/Chromium devs out there.  I would love to hear why Chrome does that.  I can only guess why, but my theory is that it's related to dynamic C-E and range requests.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0112.html

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Saturday, 21 June 2014 17:56:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC