11.33 StoreSwapInFileOpened: ... Size mismatch

Получил подобное сообщение в моем cache.log. Я полагаю, что это значит, что содержимое индекса не совпадает с содержимым на диске.

1998/09/23 09:31:30| storeSwapInFileOpened: /var/cache/00/00/00000015: Size mismatch: 776(fstat) != 3785(object)

1998/09/23 09:31:31| storeSwapInFileOpened: /var/cache/00/00/00000017: Size mismatch: 2571(fstat) != 4159(object)

Что делает Squid в этом случае?

ЗАМЕТЬТЕ, что это сообщение специфично для Squid-2. Это случается, когда Squid читает объект для хита. После открытия файла Squid проверяет совпадает ли ожидаемый им размер с тем? что ест ьна самом деле. Если размер не совпадает, то генерируется сообщение о ошибке. В этом случае Squid не посылает поврежденный объект клиенту. Он получит объект заново из источника.

11.34 Почему я получаю fwdDispatch: Cannot retrieve 'https://www.Buy.Com/corp/ordertracking.Asp' ?

Эти сообщения появляются из-за ошибок в клиентской программе, в основном в Netscape Navigator. Что происходит, когда Netscape посылает HTTPS/SSL запрос по установленному HTTP-соединению. Обычно, когда Squid получает SSL-запрос, это выглядит так:

CONNECT www.buy.com:443 HTTP/1.0

Squid открывает TCP-соединение с хостом назначения на нужном порту и настоящий запрос посылается зашифрованым по этому соединению. Это основополагающий принцип SSL - вся информация должна посылатся зашифрованной.

Однако из-за ошибки клиента Squid получает запрос типа:

GET https://www.buy.com/corp/ordertracking.asp HTTP/1.0

Accept: */*

User-agent: Netscape ...

...

Теперь все загловки и тела сообщений посылаются незашифрованными к Squid. Нет способа преобразовать этот запрос в SSL при помощи Squid. Все что мы можем сделать - вернуть сообдение о ошибке.

Заметьте, что этот баг броузера связан с риском с точки зрения безопасности, т.к. броузер ппересылает по сети важную для вас информацию в незашифрованном виде.

11.35 Squid не может получить url-ы типа http://3626046468/ab2/cybercards/moreinfo.Html

от Dave J Woolley (DJW at bts dot co dot uk)

Это неверные URL-лы, в основном используемые нелегальными сайтами. Обычно это web-сайты, которые поддерживают спамеров и скорее всего они живут на несколько часов дольше, чем учетная запись спамера.

Их цели таковы:

• обойти фильтрующие правлиа на прокси и возможно заставить некоторые броузеры считать, что этому сайту можно доверять и он находится в локальной интранет;

• обойти whois (?);

• заставить людей думать, что они не имеют IP-адреса и доменого имени, при попытке получить подобные данные, чтобы пожаловаться ISP.

Любые прокси и броузеры, которые поддерживают подобное, делают это на свой страх и риск.

RFC 1738 описывает имя хоста в URL:

Полностью определяемое доменное имя сетевого узла или его IP-адрес указывается в виде четырех групп десятичных цифр разделенных знаком ".". Форма полностью определяемого доменного имени прописывается в Секции 3.5 RFC 1034 [13] и Секции 2.1 RFC 1123 [5]: последовательность доменных указателей разделена знаком ".", каждый доменный указатель начинается и заканчиватся алфавитно-цифровым знаком и может содержать символ "-". Правый крайний указатель домена никогда не начинается с цифры, что собственно и отличает все доменные имена от IP-адресов.