Утилита wget. Бага определения типа файла.

[RXL]

Интересная бага попалась. Вернусь домой, опишу детальнее. Пока, чтобы не потерять тут привожу логи. Взаимосмязанные вещи выделил цветом.

---request begin---
GET /large-file.tar.bz2 HTTP/1.0
Referer: http://example.com/
Range: bytes=3359124103-
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: example.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 416 Requested Range Not Satisfiable
Server: nginx/1.4.1
Date: Thu, 23 May 2013 13:50:45 GMT
Content-Type: text/html
Content-Length: 212
Connection: close
Content-Range: bytes */3359124103

---response end---
416 Requested Range Not Satisfiable

    The file is already fully retrieved; nothing to do.

Кратко суть такова: файл уже имеется, но с ключом -c wget делает попытку его докачать, на что получает ответ 416 — это все нормально, но далее wget начинает сканировать файл как html в поисках ссылок (ключ -r), но это не html и размер в 3.2 ГБ не дает шанса wget на 32-бит машине (по strace видно, что он использует mmap).

Я думаю, что wget приписывает файлу MIME из Content-Type ответа 416, хотя Content-Type относится к тексту ошибки.

Кроме как написать разработчикам других идей нет?

[RXL]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626992
Бага два года назад описана. Версия та же: 1.12. Только это саппорт Дебиан. Они переправили репорт в GNU:
https://savannah.gnu.org/bugs/index.php?33833
С тех пор вышла 1.13 и 1.14. Осталось убедить RedHat.

Просмотрел историю изменений с 1.12: бага не исправлена.

[RXL]

Мой патч, делающий самое простое: если 416, то не HTML. Более правильно было бы выполнить HEAD-запрос и взять MIME из Content-Type.

Код: (Diff) wget-1.12-http_416_mime.patch

diff -urN wget-1.12/src/http.c wget-1.12-rxl-patch/src/http.c
--- wget-1.12/src/http.c        2009-09-22 07:02:18.000000000 +0400
+++ wget-1.12-rxl-patch/src/http.c      2013-05-24 13:20:46.000000000 +0400
@@ -2167,9 +2167,9 @@
   /* If content-type is not given, assume text/html.  This is because
      of the multitude of broken CGI's that "forget" to generate the
      content-type.  */
-  if (!type ||
+  if (statcode != HTTP_STATUS_RANGE_NOT_SATISFIABLE && (!type ||
         0 == strncasecmp (type, TEXTHTML_S, strlen (TEXTHTML_S)) ||
-        0 == strncasecmp (type, TEXTXHTML_S, strlen (TEXTXHTML_S)))
+        0 == strncasecmp (type, TEXTXHTML_S, strlen (TEXTXHTML_S))))
     *dt |= TEXTHTML;
   else
     *dt &= ~TEXTHTML;

Реальный прогон показал, что проблема исчезла. Подозреваю, что обратная проблема возникнет, если уже скачанный файл будет html (т.е. тот, который надо сканировать на ссылки).