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


2

У меня есть свой собственный сервер, на котором работает 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

Какую команду вы используете?
Деннис

Я не хочу публично указывать свой сервер здесь, но точная команда будет выглядеть как «curl -I myserver.com/myfile.zip ». Так что просто "curl -I", а затем URL-адрес файла, который я хотел бы скачать.
user85116

Accept-Изменяется заголовок сам по себе не имеет никакого значения. Что произойдет, если вы просто укажете диапазон (например, curl --range 0-100 URL)?
Деннис,

Это не имеет никакого значения ... это показывает, что что-то очень странное происходит между двумя соединениями ISP. Если бы в обоих соединениях отсутствовала одинаковая информация заголовка, вы были бы правы (не имеют значения), но здесь явно происходит что-то странное. Выполнение URL-адреса curl --range 5-10 дает мне весь файл на моем обычном интернет-провайдере, но дает мне запрошенные 6 байтов на моем сотовом интернет-провайдере.
user85116

Сам по себе не имеет значения , т. Е. Если частичные загрузки сработали. Не могли бы вы выполнить эти команды и опубликовать вывод? echo > tempfile; wget -d -c -O tempfile redtwitz.com
Деннис

Ответы:


2

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заголовок или нет, и на самом деле не нужно указывать диапазон для первый запрос в любом случае, так как он пытается загрузить весь ресурс, а не только его часть.


Спасибо Аарон за ваши комментарии. Но на данный момент я даже не загружаю ничего, нет частичных файлов ... Я просто выбираю и отображаю заголовки http; это оно! Я могу переключаться между двумя сетевыми подключениями 10 раз, выполняя "curl -I myfile.zip " 5 раз с каждым подключением ... 5 раз с моим настоящим провайдером, я не получаю Accept-Ranges, 5 раз с моим подключением blackberry я действительно получить это.
user85116

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

Игнорирование заголовка и затем просто попытка загрузить диапазон байтов не работает на моем обычном интернет-провайдере; curl заканчивает тем, что загружал весь файл. Но переключение на моего сотового провайдера дает правильный диапазон байтов ...
user85116

Ну, это просто странно. Также маловероятно, что ваш интернет-провайдер или сетевое оборудование должны фильтровать только те заголовки из трафика HTTP, и ничего больше; возможно ли, что ваш экземпляр lighttpd каким-то образом неправильно настроен для получения этого результата? Я знаю, что это длинный сценарий, но, похоже, он немного более правдоподобен, чем другие.
Аарон Миллер

Я попытался запустить тот же тест с другим сервером в другой стране; тот же результат, что и мой собственный сервер. Тот факт, что я не могу вообще приостановить / возобновить загрузку с помощью инструментов загрузчика, заставляет меня думать, что проблема на моем конце, а не на стороне сервера ...
user85116
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.