Браузер и wget загружают JPEG по-разному? - PullRequest
Новая
       26

Браузер и wget загружают JPEG по-разному?

9 голосов
/ 01 апреля 2011

Я поставлен в тупик на этом. Попробуйте загрузить это изображение в браузер, а затем сохраните его на жестком диске.

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

Это допустимый файл JPEG с размером 11377 байт.

Теперь попробуйте загрузить его с wget или curl. Отображается только 11252 байта, а правая нижняя часть изображения отсутствует.

Что дает?

Ответы [ 2 ]

13 голосов
/ 01 апреля 2011

Здесь идет…

Принимая дамп пакета, я вижу, что Facebook возвращает то же самое Content-Length в Safari, как и для скручивания, и что длина контента равна Неправильно 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

И с 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

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

(обратите внимание, что я использовал HTTP / 1.0 , чтобы серверы Facebook не пытались держать соединение открытым)

Удаляя первые 10 строк ouput с помощью текстового редактора, а затем сохраняя его как output.jpg, я получил полное изображение.

Таким образом, это подтверждает, что Facebook отправляет неверные Content-Lengthзаголовок (и изображение обрезается, потому что curl обращает внимание на длину содержимого, а netcat нет).

Копая немного дальше, кажется, что Алески прав: Content-Length правильно, когдаизображение отправлено сжатым gzip.Чтобы подтвердить это, я добавил Accept-Encoding: gzip в мой файл headers.Facebook корректно отправляет ответ gzip, который является ожидаемой длиной, и его распаковка приводит к правильному изображению.

tl; dr : Content-Length в Facebook неправильный, если Content-Encoding не gzip.

4 голосов
/ 01 апреля 2011

Кажется, сервер неисправен.Когда я тестировал его, разница между firefox и wget заключалась в том, что firefox указывал, что он принимает ответы на свой запрос, сжатые gzip или deflate, тогда как wget этого не сделал.

Ответ сервера на firefox составил 11252 байта сжатых данных.и его ответ на wget составил 11377 байт несжатых данных.Вместе с тем длина отправленного им содержимого равнялась обоим (как уже сказал Дэвид) по 11252.

Другими словами, кажется, что сервер кэширует сжатую версию и неправильно отправляет сжатый размер даже при отправке данных без сжатия.,Вы получаете все данные, но поскольку сервер объявляет меньше данных, wget (и другое программное обеспечение, которое запрашивает несжатые данные) отбрасывает «лишние» данные.

...