КонтактыИскать

Главная страница
Главная Тех. поддержка

Apache FAQ

______________________________________________________________

Q: У меня ничего не работает
A:

Корректно ответить на этот вопрос невозможно, но наиболее частые причины такие:
 
Вы скомпилировали Apache без mod_charset или без ключа компиляции -DRUSSIAN_APACHE. Проверить это очень просто - httpd -l выдает список модулей, среди них должен присутствовать mod_charset.c.
Часто это происходит от того, что в качестве заготовки файла Configuration берут Configuration.tmpl, в котором mod_charset.c отсутствует.
В вашем файле конфигурации отсутствуют директивы настройки перекодировок. В этом случае сервер работает (во всяком случае должен) в точности как обычный Apache
Вы проверяете все каким-то броузером, который корректно показывает любой charset (MS IE 3-4.x, Netscape 4.x, Lynx 2.6+). В этом случае сервер производит все перекодировки, но клиент этого не видит. Единственный способ действительно проверить работу сервера - это использовать telnet www.yourdomain.ru 80 или что-то в этом духе (netcat, netpipes и т.д.). 
______________________________________________________________

Q: Перекодировка работает, но не для всех URL

A:

Проверьте, описана ли таблица перекодировки для данного сочетания клиентской кодировки и кодировки хранения. Если таблица не описана, то сервер сам построит "пустую" таблицу, т.е. никакой кодировки не будет.

______________________________________________________________ 
Q: Не работает перекодировка в транслитерацию

A:

Проверьте, не используете ли вы случайно директиву CharsetRecodeTable вместо правильной директивы CharsetWideRecodeTable
 
______________________________________________________________

Q: Перекодируются все file uploads

A:

Это - feature.

Варианты решения:
запретите все перекодировки для скрипта, который разбирает FileUpload, например таким способом:
<Location /path/to/upload.cgi>
CharsetDisable On
</Location>
    
и делайте перекодировку сами.


Используйте директиву CharsetRecodeMultipartForms, которая появилась в PL23, но при этом вам все-равно придется перекодировать вручную текстовые части запросов. Для этого можно использовать Russian Apache API, доступное в других модулях или Russian Apache Perl API, доступное из mod_perl.


______________________________________________________________ 
Q: Перекодируются PUT-запросы

A:

Это - тоже feature. Решений тоже два:
Запретить перекодировку для данного скрипта:
Script PUT /path/to/put.cgi
<Location /path/to/put.cgi>
CharsetDisable On
</Location>
    
Используя директиву CharsetRecodeMethodsIn (появилась начиная с PL23) запретить перекодировку для метода PUT. 

______________________________________________________________ 
Q: Не перекодируются или перекодируются неправильно запросы к CGI

A:

При обработке CGI и определении кодировки по URL, кодировка определяется по URL CGI-скрипта. Если вы используете определение кодировки по префиксу директории (/win/file.html), а скрипт имеет URL /cgi-bin/myscript.sh, то результат очевиден.

______________________________________________________________ 
Q: Не пeрекодируются proxy-запросы

A:

И не должны. Корректная перекодировка proxy-запросов в общем случае нереальна - далеко не все серверы сообщают о кодировке отдаваемого документа т.е. нельзя узнать из какой кодировки нужно перекодировать в кодировку клиента.

Если вы хотите использовать ProxyPass для отображения соседнего сервера в дерево документов Russian Apache с их перекодировкой (например, для решения проблем перекодировки у MS IIS, Lotus Domino и так далее), то возможны по меньшей мере два варианта:
Использование Apache::Gateway (требует mod_perl для работы).
Использование самодельного Action-script или подобного CGI, который будет сам делать запросы к удаленному серверу, а затем выдавать их клиенту.

______________________________________________________________ 
Q: При перекодировке "по портам" с одновременным использованием Virtual Hosts, при обращении к виртуальному хосту по порту, отличающемуся от 80 происходит обращение к основному серверу

A:

Сначала прочитайте документацию к оригинальному Apache. Потом найдите у себя в конфигурации строчку
<VirtualHost vhost.my.domain>
и замените ее на
<VirtualHost vhost.my.domain:*>

______________________________________________________________ 
Q: При использовании NameVirtualHost и <VirtualHost somename:*> все-равно не работает перекодировка "по портам" - сервер ругается "mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results"

A:

Найдите в конфигурационном файле директиву Port и удалите ее - при Listen на нескольких портах она только мешает.

______________________________________________________________ 
Q: Мой скрипт порождает ссылку на самого себя вместе с параметрами. В параметрах есть русские буквы, которые закодированы как %AA%BB. При обращении по этому URL, на сервер приходят данные, перекодированные дважды.

A:

При выдаче html-документа клиенту происходит только "побуквенная" перекодировка, сам HTML не парсится и элементы вида <a href="script.cgi?param=%AA%BB%CC%DD"> не перекодируются. При этом клиент получает такие URL в кодировке сервера. В то же время, строки GET-запросов с param=%AA%BB%CC%DD перекодируются из кодировки клиента в кодировку сервера. Чтобы все было хорошо, необходимо писать ссылки (HREF) открытым текстом: <a href="script.cgi?param=русский+текст">.

Второй вариант, более соответствующий стандартам, - писать все в виде %AA%BB, но в кодировке клиента. Для этого можно использовать Russian Apache API (в модулях) и Russian Apache Perl API - в модулях, написанных для mod_perl и скриптах, исполняемых под Apache Registry.

______________________________________________________________ 
Q: Не могу собрать вместе Russian Apache и PHP в виде модуля

A:

Возьмите PHP версии 3.0.2a или новее. Там появилась поддержка Russian Apache, которая включается через ./configure --with-mod_charset.

______________________________________________________________ 
Q: Выдача FastCGI не перекодируется

A:

FastCGI использует для вывода не стандартные функции Apache API, а функцию bwrite, вывод которой не перекодируется. Возьмите патч здесь (если используется Russian Apache 1.3.x или новее, то слова USE_TRANSFER_TABLES нужно заменить на RUSSIAN_APACHE).

______________________________________________________________ 
Q: Зачем вообще сервер выдает заголовок Expires ? Это не дает кэшировать документы

A:

Заголовок Expires: выдается сервером именно для того, чтобы избежать кэширования этих документов в "транзитных" proxy-серверах. Допустим на секунду, что такой заголовок не выдается. Допустим, пользователь с Unix (кодировка koi8) пришел на ваш сервер http://yourserver.ru через прокси cache.yourserver.ru. Т.к. документы можно кэшировать, то в прокси осядет этот документ в кодировке koi8. Следующий пользователь того же proxy получит этот документ в koi8, даже если его родная кодировка - cp1251. Придется жать Reload, но скажем поисковые серверы этого делать не будут.

Вывод простой - если один и тот же URL может иметь разное содержимое (кодировки), то он не должен кэшироваться. Кэшироваться могут только документы, кодировка которых определяется по URL, а не по заголовкам, пришедшим от документа.

HTTP/1.1 позволяет более тонко управлять кэшируемостью через заголовок Vary:. Russian Apache поддерживает этот механизм и не выдает Expires на HTTP/1.1 запросы.

Чтобы избежать выдачи некэшируемых документов, необходимо сразу перенаправлять клиента на URL, для которого выдается кэшируемый документ. Как это сделать написано выше.

______________________________________________________________ 
Q: Я использую AutoRedirect. Как сделать так, чтобы поисковые системы не получали его, а получали сам документ ?
A:

Варианты решения:
Если вы имеете в виду конкретную поисковую систему, то проще всего использовать настройку вроде такой:
BrowserMatch my-cool-spider CHARSET_NOREDIRECT
Если хочется, чтобы все неизвестные User-Agents не получали redirect, то возможно вам поможет директива CharsetNoRedirectForDefaultCharset. Эта директива поддерживается начиная с версии сервера 1.3.6 rus/PL28.16.

______________________________________________________________

Q: Мне нужно использовать одновременно Russian Apache и SSL, но не получается даже их собрать
A:

Варианты решения:
Общий случай. И Russian Apache и mod_ssl требуют внесения изменений в исходные тексты самого Apache (т.е. не могут быть реализованы как независимые модули). К сожалению, часть правок производится в одних и тех же файлах (для Apache 1.3.9 и mod_ssl 2.4.1 это htdocs/index.html, Makefile.tmpl, src/include/httpd.h). Правки вносятся утилитой patch которая работает по контексту. Если контекст нарушен "чужими" правками, то автоматически нужные изменения внесены быть не могут.
Поэтому наиболее общий порядок действий такой - взять Russian Apache нужной версии, взять mod_ssl нужной версии, запустить configure от mod_ssl.
Прежде чем запускать компиляцию, нужно найти все файлы с расширением .rej - в них записываются те изменения, которые не удалось - посмотреть в них и довнести изменения руками.
Частные случаи.Russian Apache 1.3.9 PL28.18 сделан совместимым "по патчам" с mod_ssl 2.4.1. Для более поздних (и более ранних) версий возможно потребуется процедура, описанная выше.

______________________________________________________________
Q: Есть проблемы при использовании CharsetNormalizeToURL и запароленной картинке
 
A:

Да, действительно, у нетскейпа есть проблема - он обижается получив редирект-запрос пароля-еще редирект. Решение просто как все гениальное:
AuthType Basic

     require valid-user

CharsetNormalizeToURL none
  
Так как password-protected URLs все-равно не должны кэшироваться в транзитных proxy, то от предлагаемого решения никто не страдает.
 
 

 





Новости

День России
08.06.2010


NODEX - профессиональные услуги связи

А так же...