fazendo o download com pausa e retomada

Question

Eu tenho meu próprio servidor executando o lighttpd. Ao visualizar os cabeçalhos com "curl -I ..." no meu laptop através da minha conexão de internet padrão / regular, eu recebo isso:

    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

Quando eu ligo o meu laptop para a conexão do meu celular (hotspot wifi), eu corro o mesmo comando exatamente no mesmo terminal para o mesmo servidor, eu recebo de volta:

    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

Observe que "Accept-Ranges: bytes" está presente no segundo caso, mas não no primeiro.

O que pode estar causando isso? Eu preciso desesperadamente desse recurso de pausa / retomada, ele está faltando na minha conexão desde que consigo me lembrar e nunca investiguei o porquê (não apenas para o meu próprio servidor, mas para QUALQUER servidor / arquivo que eu quisesse baixar) ... De um computador diferente ao qual tenho acesso, a execução do mesmo comando curl mostra que Accept-Ranges: bytes está presente, portanto, suponho que haja algo instável com meu provedor de serviços de Internet regular aqui em casa.

O hardware de rede causaria isso? Incompatível roteador / switch talvez? Ou seria o próprio ISP?

Alguma opinião?

Como solicitado por Dennis, aqui está a saída:

    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

    

Answer 1

RFC2616 "Protocolo de Transferência de Hipertexto - HTTP / 1.1", seção 14.5:

14.5 Accept-Ranges The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource:

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

Origin servers that accept byte-range requests MAY send

 Accept-Ranges: bytes

but are not required to do so. Clients MAY generate byte-range requests without having received this header for the resource involved. Range units are defined in section 3.12.

Servers that do not accept any kind of range request for a resource MAY send

 Accept-Ranges: none

to advise the client not to attempt a range request.

Em resumo, esse é o servidor remoto informando ao UA que está disposto a aceitar uma solicitação para apenas parte do recurso em questão, conforme descrito em RFC2616 seção 14.35 . Como esse é o mecanismo pelo qual a retomada de um download com falha é implementada, ver o cabeçalho Accept-Ranges na resposta do servidor é realmente um bom sinal de que você conseguirá atingir sua meta aqui.

De fato, curl parece implementar esse recurso, conforme descrito aqui ; as duas formas dadas do comando são:

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

e

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

Parece-me que ambas as formas devem comportar-se de forma mais ou menos idêntica, mas também não tentei, por isso não posso ter a certeza. Supondo que o Curl se comporte como anunciado, você deve simplesmente reemitir o mesmo comando (possivelmente com pequenas modificações, como na primeira forma em que você precisaria alterar os nomes dos arquivos) sempre que precisar retomar o download, e o Curl examinará o que você baixou até agora e emite um cabeçalho Range especificando apenas os bytes restantes no arquivo.

Por que você não está vendo o cabeçalho Accept-Ranges na resposta à sua solicitação original, talvez haja algum estado de alerta por parte do servidor, de modo que ele reconheça a segunda solicitação do seu UA para o mesmo recurso que inclui o cabeçalho Accept-Ranges para garantir que seu UA esteja ciente de que uma tentativa de retomar o download será bem-sucedida. Em qualquer caso, isso não deve importar particularmente; de acordo com a citação do RFC acima, seu cliente pode (na ausência de um cabeçalho Accept-Ranges: none pré-existente do servidor) emitir uma solicitação de intervalo de bytes se já viu o Accept-Ranges ou não, e realmente não precisaria para especificar um intervalo na primeira solicitação em qualquer caso, já que ele está tentando baixar o recurso inteiro em vez de apenas parte dele.