|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ramazan Ja-Far 2:5020/400 14 Oct 2002 02:55:16
To : Victor Wagner
Subject : Re: teleport
--------------------------------------------------------------------------------
Hi!
On Sun, 13 Oct 2002 05:33:58 +0000 (UTC), Victor Wagner wrote:
RJF>> Допустим, есть domain accept/reject и extension
RJF>> accept/reject, когда проще и эффективнее было-бы
RJF>> использовать URL regex.
VW>Ты бы этот ман прочитал что-ли.
Я его читал, когда писал ответ. У меня есть debian,
живущий в chroot; в нём я закачал wget 1.8.1-6.
-A acclist --accept acclist
-R rejlist --reject rejlist
Specify comma-separated lists of file name suffixes or
patterns to accept or reject
Hе сказано, что за patterns и against what are they being
matched. Потому я оставил своё замечание насчёт regex.
VW>У wget в этом плане куда гибче. Ты можешь ограничить
VW>а) определенным хостом
--domains
--exclude-domains
VW>б) поддеревом URL от исходной страницы вниз
--no-parent
VW>в) всем что на данной странице отображается
VW>(картинки и css-ы брать, а ссылки не брать)
VW>и еще десятком вариантов.
--page-requisites
Hу что, пан Вагнер, я справился с домашним
заданием :)?
Однако, эту старую собаку (wget) сложно научить
новым трюкам. По крайней мере, про десяток
вариантов это преувеличение.
Скажем, к чему 5 опций: domain acc/rej
+ suffix acc/rej + no-parent?
Когда, в принципе, алгоритм очень прост:
1) имеем список исходных URLs, для каждого есть
потенциал рекурсии;
2) закачиваем [первый] URL, (если список пуст,
выходим) смотрим, можно ли из него отпарсить
список URLs/requisiteURLs;
используем такие параметры как --follow-tags,
--ignore-tags, --relative;
3) вычисляем остаток потенциала рекурсии для списка;
используем --page-requisites;
4) смотрим, какие URLs are followable; пользуемся
domain acc/rej + suffix acc/rej + no-parent;
5) добавляем оставшиеся после п.4 URLs к основному
списку и идём к п.2
Так вот, параметры в п.2 - глобальные, когда
можно сделать parent-URL зависимыми.
Поведение п.4 зависит от 5 параметров (из них
4 списка), когда можно обойтись одним списком
regex.
VW>Интересен не только факт, закачан ли файл полностью, а также
VW>и насколько он закачен.
8-()?
При предложенной мне схеме об этом скажет
размер временного файла (если он закачан не
полностью). Если временного файла нет - URL
закачан полностью.
RJF>> И, естественно, нужен способ проверки валидности
RJF>> частично закачанных файлов. Т.е. нужно где-то
RJF>> запоминать характеризующую ресурс информацию из
RJF>> заголовков HTTP "Content-Type", "Content-Length",
RJF>> "Last-Modified", "ETag".
VW>Content-Type запоминать не обязательно. Имя есть, и ладно.
VW>Content-Length с очевидностью возвращает системный вызов stat.
VW>Last-Modified - тоже, хотя и с меньшей очевидностью.
Ты не понял.
1)
Content-Length показывает, каким должен быть
временный файл. Он же по определению неполный.
stat выдаст значение, меньшее Content-Length,
выданного сервером в исходном ответе.
И кроме того, файл на сервере за это время мог
поменяться. О факте изменения мы можем судить
в т.ч. по сообщаемому размеру. Это очень
существенная характеристика. По крайней мере,
серверы чаще её сообщают, чем Last-Modified.
2)
Last-Modified можно штамповать на временном
файле при обрыве, при получении сигнала (SIGTERM,
SIGKILL), но это требует перехватки сигнала
в программе. К чему лишний геморрой? А если
просто вырубилось питание? Это не обрабатывается.
Кусок недописанного файла останется, если fs
достаточно надёжна (ext3 and similar), но на
нём будет проставлено время отрубания питания
(+/-пара секунд).
Так что лучше сложить Last-Modified "сбоку".
3)
Content-Type тоже полезен. К примеру, вчера по
URL выдавали image/jpeg, а сегодня решили докачать,
но там уже дают text/html.
--
Bye!
Ramazan
--- ifmail v.2.15dev5
* Origin: Svit Online (post does not reflect views of Golden Tele (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
