загрузка с паузой и возобновлением

У меня есть свой собственный сервер, на котором работает lighttpd. При просмотре заголовков с помощью «curl -I ...» на моем ноутбуке через стандартное / обычное подключение к Интернету, я получаю следующее:

    HTTP/1.1 200 OK
Content-Type: application/zip
ETag: "546653951"
Last-Modified: Wed, 08 May 2013 15:35:42 GMT
Content-Length: 28166067
Date: Wed, 08 May 2013 19:07:36 GMT
Server: lighttpd/1.4.28

Когда я переключаю свой ноутбук на соединение с мобильным телефоном (точка доступа Wi-Fi), я запускаю точно такую ​​же команду в том же терминале на том же сервере, я получаю следующее:

    HTTP/1.1 200 OK
Content-Type: application/zip
Accept-Ranges: bytes
ETag: "546653951"
Last-Modified: Wed, 08 May 2013 15:35:42 GMT
Content-Length: 28166067
Date: Wed, 08 May 2013 19:09:23 GMT
Server: lighttpd/1.4.28

Обратите внимание, что «Accept-Ranges: bytes» присутствует во втором случае, но не в первом.

Что может быть причиной этого? Мне отчаянно нужна эта возможность паузы / возобновления, она отсутствовала в моем соединении до тех пор, пока я себя помню, и просто никогда не выяснял почему (не только для моего собственного сервера, но и для ЛЮБОГО сервера / файла, который я хотел загрузить) ... С другого компьютера, к которому у меня есть доступ, выполнение той же команды curl показывает, что Accept-Ranges: bytes присутствует, поэтому я предполагаю, что с моим обычным интернет-провайдером у меня дома что-то не так.

Будет ли это причиной сетевое оборудование? Возможно, несовместимый маршрутизатор / коммутатор? Или это будет сам провайдер?

есть идеи?

По просьбе Денниса, вот результат:

    echo > tempfile; wget -d -c -O tempfile redtwitz.com
Setting --continue (continue) to 1
Setting --output-document (outputdocument) to tempfile
DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2013-05-10 12:20:48--  http://redtwitz.com/
Resolving redtwitz.com (redtwitz.com)... 184.22.37.72
Caching redtwitz.com => 184.22.37.72
Connecting to redtwitz.com (redtwitz.com)|184.22.37.72|:80... connected.
Created socket 4.
Releasing 0x00000000013d1310 (new refcount 1).

---request begin---
GET / HTTP/1.1
Range: bytes=1-
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: redtwitz.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 200 OK
Date: Fri, 10 May 2013 16:21:56 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Thu, 02 Aug 2012 13:41:17 GMT
ETag: "a819c40-d-4c64890da1940"
Content-Length: 13
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

---response end---
200 OK
Registered socket 4 for persistent reuse.
Length: 13 [text/html]
Saving to: `tempfile'

100%[================================================================>] 13          --.-K/s   in 0s      

2013-05-10 12:20:49 (783 KB/s) - `tempfile' saved [13/13]

more tempfile

edtwitz.com

RFC2616 «Протокол передачи гипертекста - HTTP / 1.1», раздел 14.5:

14.5 Accept-Ranges Поле заголовка ответа Accept-Ranges позволяет серверу указать, что он принимает запросы диапазона для ресурса:

 Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
 acceptable-ranges = 1#range-unit | "none"

Исходные серверы, которые принимают запросы диапазона байтов, МОГУТ отправить

 Accept-Ranges: bytes

но не обязаны это делать. Клиенты МОГУТ генерировать запросы диапазона байтов, не получив этот заголовок для задействованного ресурса. Единицы измерения диапазона определены в разделе 3.12.

Серверы, которые не принимают какой-либо запрос диапазона для ресурса, МОГУТ отправить

 Accept-Ranges: none

советовать клиенту не пытаться запросить диапазон.

Короче говоря, это удаленный сервер, который сообщает вашему UA о своем желании принять запрос только для части соответствующего ресурса, как описано в разделе 14.35 RFC2616 . Поскольку это механизм, с помощью которого осуществляется возобновление неудачной загрузки, просмотр Accept-Rangesзаголовка в ответе сервера на самом деле является хорошим признаком того, что вы сможете достичь своей цели здесь.

Действительно, curlкажется, для реализации этой возможности, как описано здесь ; две формы, данные команды:

cat file-that-failed-to-download.zip | curl -C - http://www.somewhere.com/file-I-want-to-download.zip >successfully-downloaded.zip

а также

curl -C - -o partially_downloaded_file 'www.example.com/path/to/the/file'

Мне кажется, что обе формы должны вести себя более или менее одинаково, но я тоже не пробовал, поэтому не уверен. Предполагая, что Curl ведет себя так, как объявлено, вы сможете просто повторять одну и ту же команду (возможно, с небольшим изменением, как в первой форме, где вам нужно будет изменить имена файлов) каждый раз, когда вам нужно возобновить загрузку, и Curl проверит то, что вы скачали до сих пор, и выдайте Rangeзаголовок, указывающий только оставшиеся байты в файле.

Что касается того, почему вы не видите Accept-Rangesзаголовок в ответе на ваш исходный запрос, возможно, со стороны сервера имеется некоторая информация о состоянии, такая, что он распознает второй запрос от вашего UA для того же ресурса и включает в себя Accept-Rangesзаголовок, чтобы убедиться, что ваш UA знает, что попытка возобновить загрузку будет успешной. В любом случае, это не должно иметь особого значения; согласно приведенному выше RFC, ваш клиент может (при отсутствии ранее существующего Accept-Ranges: noneзаголовка с сервера) выдать запрос диапазона байтов, независимо от того, уже виден Accept-Rangesзаголовок или нет, и на самом деле не нужно указывать диапазон для первый запрос в любом случае, так как он пытается загрузить весь ресурс, а не только его часть.