¿El navegador y wget cargan JPEG de manera diferente?

Question

Estoy perplejo en este caso. Intente cargar esta imagen en su navegador y luego guárdela en su disco duro.

http://profile.ak.fbcdn.net/hprofile-ak-snc4/41674_660962816_995_n.jpg

Es un archivo JPEG válido en 11377 bytes.

Ahora intenta descargarlo con wget o curl. Solo aparecen 11252 bytes y falta la parte inferior derecha de la imagen.

¿Qué ofrece?

Answer 1

Aquí va ...

Tomar una descarga de paquetes, veo que Facebook vuelve la misma Content-Length a Safari como lo hace para rizar, y que el contenido de longitud es el incorrecta 11252:

 
GET /hprofile-ak-snc4/41674_660962816_995_n.jpg HTTP/1.1 
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 
Host: profile.ak.fbcdn.net 
Accept: */* 

HTTP/1.1 200 OK 
Content-Type: image/jpeg 
... snip .... 
Content-Length: 11252 

Y con Safari:

 
GET /hprofile-ak-snc4/41674_660962816_995_n.jpg HTTP/1.1 
Host: profile.ak.fbcdn.net 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27 
... snip ... 

HTTP/1.1 200 OK 
Content-Type: image/jpeg 
... snip ... 
Content-Length: 11252 

Así que voy a adivinar Facebo está enviando una longitud de contenido incorrecta. Para probar esto, voy a usar netcat:

 
$ cat headers 
GET /hprofile-ak-snc4/41674_660962816_995_n.jpg HTTP/1.0 
Host: profile.ak.fbcdn.net 
Accept: */* 

EOF 
$ nc -vvv profile.ak.fbcdn.net 80 output 
Warning: Inverse name lookup failed for `142.231.1.174' 
Notice: Real hostname for profile.ak.fbcdn.net [142.231.1.165] is a142-231-1-165.deploy.akamaitechnologies.com 
profile.ak.fbcdn.net [142.231.1.174] 80 (http) open 
Total received bytes: 12k (11639) 
Total sent bytes: 97 
$ head output 
HTTP/1.0 200 OK 
Content-Type: image/jpeg 
... snip ... 
Content-Length: 11252 

(tenga en cuenta que he usado HTTP/1.0 por lo que los servidores de Facebook no tratar de mantener la conexión abierta)

Extracción de las primeras 10 líneas de ouput usando un editor de texto y guardándolo como output.jpg, tengo la imagen completa.

Esto confirma que Facebook está enviando un encabezado Content-Length incorrecto (y la imagen se está cortando porque curl está prestando atención a la longitud del contenido, mientras que netcat no lo está).

Cavando un poco más, parece que Aleski está en lo cierto: el Content-Length es correcto cuando la imagen se envía gzip-compressed. Para confirmar esto, agregué Accept-Encoding: gzip a mi archivo headers. Facebook envía correctamente una respuesta gzip'd que es la longitud esperada, y al descomprimirla se obtiene la imagen correcta.

tl; dr: Facebook de Content-Length es incorrecto si el Content-Encoding no es gzip.

Answer 2

Parece que el servidor está defectuoso. Cuando lo probé, la diferencia entre firefox y wget fue que Firefox indicó que acepta gzip o deflate -comprimió las respuestas a su solicitud, mientras que wget no lo hizo.

La respuesta de los servidores a firefox fue 11252 bytes de datos comprimidos, y su respuesta a wget fue 11377 bytes de datos sin comprimir. La longitud del contenido que envió fue, sin embargo, 11252 para ambos (como David ya dijo).

En otras palabras, parece que el servidor está almacenando en caché la versión comprimida y enviando incorrectamente el tamaño comprimido incluso al enviar los datos sin comprimir. Obtienes todos los datos, pero como el servidor anuncia menos datos, wget (y otro software que solicita datos sin comprimir) descarta los datos "adicionales".