/usr/local/apache/htdocs/lib/public_html/book/WEBMASTER/apachlexa.txt Библиотека на Meta.Ua Русский Apach 1.3 имени Дмитрия Крюкова
<META>
Интернет
Реестр
Новости
Рефераты
Товары
Библиотека
Библиотека
Попробуй новую версию Библиотеки!
http://testlib.meta.ua/
Онлайн переводчик
поменять

Русский Apach HTTP server от Дмитрия Крюкова

Оригинал этого документа а так же все связанные с ним файлы
лежат на сервере Алекса Тутубалина http://apache.lexa.ru/ Ў http://apache.lexa.ru/



1. Краткий обзор сервера



За основу сервера был взят популярный сервер
Apache/1.1.3.
Текушая версия данного сервера Apache/1.1.3 rus/PL14.
Последняя веpсия, считающаяся стабильной - Apache/1.1.3 rus/PL12.
Здесь можно узнать обо всех изменениях
в данном сервере по сравнению с предыдущими платформами. Рекомендую
просмотреть эти изменения так как они значительны. Также рекомендую
тщательно изучить разделы Как настроить и
Некоторые рекомендации.
Особенностями сервера являются:

  1. Поддержка согласования кодировок клиента и сервера.
  2. Выдача правильных Content-type:...;charset=... в соответствии с
    этим согласованием.
  3. Выдача при необходимости заголовка Expires: для proxy серверов.
  4. Поддержка Ranges.
  5. Поддержка возможности не записывать в logfile ненужные адреса.

В сервере реализовано совмещение нескольких методов согласования
кодировок клиента и сервера, а именно:

Схема согласования

    • Через заголовки клиента Accept-Charset: и/или
      Accept: text/x-cyrillic ...
      Если сервер знает о том charset, который запросил клиент, то эти
      заголовки имеют высший приоритет для сервера, вне зависимости от его
      настройки на native charset.
    • Через поиск в имени сервера названия одной из сконфигурировнных
      кодовых страниц (например: www-koi8-r.stack.serpukhov.su или
      www-windows-1251.stack.serpukhov.su)
    • Через поиск в преффиксе запрошенного URI названия одной из
      сконфигурировнных кодовых страниц (например:
      http://www.stack.net/windows-1251/file.html)
    • Через конфигурацию кодовых страниц по умолчанию для различных
      типов клиентских программ в случае, когда сервер может опознать
      клиентскую программу (иногда среду, в которой работает клиентская
      программа).
    • Через текущее дерево. Т.е. администратор может запустить несколько
      серверов на разных портах, или описать в конфигурации сервера несколько
      виртуальных серверов. В обоих случаях для разных реальных или виртуальных
      серверов устанавливается свой charset по умолчанию. После этого,
      администратор может планировать дерево в разных кодировках. Естественно,
      само дерево документов в таком случае хранится в единственном экземпляре.
    • В случае принятия сообществом единой транспортной кодировки,
      необходимо будет оставить только ее в сервере, независимо от физического
      способа представления данных документов.

Некоторые особенности:

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

    Сервер корректно преобразует
    текстовые потоки от/к клиенту, включая последовательности
    типа %xx%yy%zz.
  • Администратор сервера может указывать характерные признаки
    клиентской программы (User-agent: заголовок) и соответствующий
    данной клиентской программе charset по-умолчанию.
  • Администратор сервера может указать клиентские программы,
    которые неадекватно воспринимают MIME, для них такие заголовки
    сервером не будут выдаваться.
  • Администратор сервера может указать приоритет в выборе
    сервером charset между URL и User-agent.
  • Администратор сервера может определить реакцию сервера
    на некорректно запрошенный charset (т.е. выдавать ли
    запрошенный документ в таком случае в charset по-умолчанию)
  • Использование в URL фрагмента файла. Данная возможность
    позволяет серверу переслать клиенту не весь требуемый документ
    а только необходимую его часть (например, ссылки на результат
    поиска WAIS в больших структурированных файлах).
    Сервер воспринимает в запросе конструкцию:

    • file_name;bytes=l-m или
    • file_name;lines=l-m

    Сервер также воспринимает от клиента заголовок:

    • Range: bytes=a-b
    • Range: lines=a-b

    При этом, документу ставится Content-type: text/plain если документ был текстом
    или Content-type: application/octet - если документ является
    не текстовым.
  • Возможность исключать в конфигурационных файлах нежелательные
    адреса для записи в logfile для каждого реального и виртуального
    сервера с помощью директивы NoLog domain или NoLog aaa.bbb.ccc


2. Где взять?



Сейчас доступны две версии правок - для Apache-1.1.1 (это оригинальные
правки Дмитрия Крюкова) и для
Apache-1.1.3 (те же правки, икорпорированные в Apache-1.1.3). Старые правки
пока сохранены т.к. они показали свою работоспособность, а правки для 1.1.3
пока еще практически не тестировались.

Сам сервер Apache можно взять на
www.apache.org или
на его зеркалах.

Необходимые компоненты, реализующие указанные выше возможности
можно взять по ftp:
на сервере apache.lexa.ru
. На этот сервер будут помещаться все последующие
версии правок (исправление ошибок, правки для новых версий Apache, новые
возможности).



В настоящее время доступны:


Apache-1.1.3-RUS-pl14a (alpha-quality, будте готовы к ошибкам :) :


      Apache-1.1.3 + RUS-pl14 patches


      Только патчи, накладываемые поверх Apache-1.1.3 clean source tree


      Различия между PL12 и PL14a


      Apache-1.1.3-RUS-pl12:

      Apache-1.1.1-RUS-pl12:



      3. Как установить?



      Установка из "полного архива"



      1. Раскройте полученный архив
      2. Внесите нужные вам изменения в ./src/Configuration и/или ./src/httpd.h
      3. ./Configure && make


      Установка патчей поверх дистрибутивного Apache




      1. Раскройте "родной" архив сервера Apache.
      2. Наложите полученные с этого сервера патчи с помощью программы patch
      3. Внесите нужные вам изменения в ./src/Configuration и/или ./src/httpd.h
      4. ./Configure && make


      После этого сервер будет построен.


      4. Как настроить?



      Все вышеперечисленные возможности сервера могут быть настроены через
      конфигурационные файлы. Ниже приведено описание используемых для
      этого директив:

      CharsetTable

      Служит для описания основных charsets, используемых в сервере.
      Синтаксис следующий:

        CharsetTable Oficial_Name Table1 [Table2] Language


      Oficial_Name

      Официальное название charset (например windows-1251, koi8-r, ibm866,
      iso_8859-5:1988 и.т.д.)

      Table1

      Имя файла тавлицы, устанавливающей соответствие между внутренним
      представлением документов и документов в данном charset при передаче
      к клиенту.

      Table2

      Имя файла тавлицы, устанавливающей соответствие между внутренним
      представлением документов и документов в данном charset при приеме от
      клиента. Может отсутствовать, в этом случае используется таблица,
      обратная Table1.

      Language

      Название языка, к которому принадлежит данный charset. Это название
      должно быть определено в conf/srm.conf в директивах AddLanguage и
      LanguagePriority.

      Примеры


      CharsetTable iso_8859-5:1988 conf/koi-iso.tab ru
      CharsetTable ibm866 conf/koi-alt.tab ru
      CharsetTable windows-1251 conf/koi-win.tab ru
      CharsetTable koi8-r conf/koi-koi.tab ru

      Каждая директива описывает только один charset. Если существует несколько
      виртуальных серверов и в каждом из этих серверов есть необходимость
      использовать несколько charsets, то они должны быть описаны для каждого
      виртуального сервера в секции <VirtualHost>.


      CharsetAlias

      Служит для описания имен псевдонимов указанных charset.
      Синтаксис следующий:

        CharsetAlias Oficial_Name Alias1 Alias2 Alias3 ...


      Oficial_Name

      Официальное имя описываемого charset. Должно быть определено
      до данной директивы директивой CharsetTable.

      Alias1 Alias2 ...

      Имена псевдонимов для данного charset.

      Примеры:


      CharsetAlias iso_8859-5:1988 iso-ir-144 iso_8859-5 cyrillic iso-8859-5
      CharsetAlias iso_8859-5:1988 iso8859-5 iso-8859.5 iso8859.5 iso
      CharsetAlias ibm866 csibm866 866 cp866 x-cp866 x-ibm866 cp-866 alt
      CharsetAlias windows-1251 win x-cp1251 cp1251 cp-1251


      Все псевдонимы должны быть определены индивидуально для каждого виртуального
      сервера.

      CharsetPriority

      Служит для определения приоритетов сконфигурированных charsets.
      Может иметь значение если в запросе клиента указаны равные весовые
      коэффициенты для различных charsets или если не указан NativeCharset
      то будет использован старший. Синтаксис:

        CharsetPriority Charset1 Charset2 Charset3 ...


      Charset1 Charset2 ..

      Имена charset в порядке убывания приоритета (самый левый имеет высший
      приоритет). Все имена Charset должны быть определены до этой директивы с
      помощью CharsetTable.

      Пример:

      CharsetPriority windows-1251 koi8-r ibm866


      В именах charset должны использоваться только официальные имена, а не
      псевдонимы.

      NativeCharset

      Определяет имя chatset по-умолчанию для данного сервера. Синтаксис:

        NativeCharset Charset_Name


      Charset_Name

      Официальное имя charset по-умолчанию для данного сервера.

      Пример:


      NativeCharset koi8-r
      NativeCharset windows-1251


      Определяется для каждого виртуального сервера независимо.
      Charset_Name должно быть определено до этой директивы с помощью директивы
      CharsetTable.

      AgentCharset

      Определяет charset, который может быть использован при нахождении
      в запросе клиента подстроки, идентифицирующей данного клиента.
      Эта подстрока ищется в запросе клиента в поле User-Agent.
      Синтаксис:

        AgentCharset Charset_Name Pattern1 Pattern2 Pattern3 ...


      Charset_Name

      Официальное имя charset

      Pattern1 Pattern2 ...

      Шаблоны для поиска в запросе клиента в поле User-Agent.

      Примеры:


      AgentCharset windows-1251 AIR_Mosaic IWENG/1 MSIE WinMosaic (Windows (WinNT;
      AgentCharset windows-1251 (Win16; (Win95; (16-bit)
      AgentCharset koi8-r Arena Ariadna Macintosh OmniWeb Sextant PRD (X11
      AgentCharset ibm866 DosLynx


      Все Pattern являются подстроками, а не regexp выражениями.

      BadAgent

      Некоторые клиентские программы не могут адекватно реагировать
      на MIME, например при получении заголовка

      Content-type: text/html; charset=koi8-r; level=3

      Чтобы сервер не выдавал таким клиентским программам charset=...
      служит эта директива. Синтаксис:

        BadAgent Pattern1 Pattern2 Pattern3 ...


      Pattern1 Pattern2 ...

      Подстрока в поле User-agent запроса клиента, при нахождении
      которой сервер будет воздерживаться от выдачи charset=...
      Пример:

      BadAgent lynx arena


      Все Pattern являются подстроками, а не regexp выражениями.

      RejectErrorCharset

      Директива служит для определения сервером действий при получинии
      в запросе клиента неизвестного charset. Синтаксис:

        RejectErrorCharset On/Off

      При установке этого параметра в On сервер не будет выдавать документ в
      native charset, а будет сообщать клиенту об ошибке в запросе.
      При установке в Off - в любом случае выдаст документ как сможет.
      Значение по-умолчанию Off.

      NoHostnameCharset

      По умолчанию, если клиентом не запрошена конкретная code page
      сервер пытается ее определить по своему имени, например:
      win.www.company.com. Данная директива позволяет запретить
      серверу искать требуемый клиенту charset в своем имени.
      Синтаксис:

        NoHostnameCharset On/Off

      Значение по-умолчанию Off.

      NoUriCharset

      Директива позволяет запретить серверу определять
      требуемый клиенту charset из URI. Конкретный пример, по умолчанию сервер
      считает что документы типа:

        http://www.company.com/win/name.html

      следует выдавать в кодировке windows-1251.
      Использование директивы:

        NoUriCharset On

      заставит сервер выдать этот документ в native code page.
      CharsetAgentPriority

      Определяет приоритетность при поиске необходимого charset сервером
      между URL и User-Agent. Синтаксис:

        CharsetAgentPriority On/Off

      При установке этого параметра в On сервер в первую очередь будет
      смотреть на поле User-Agent. И если в этом поле он найдет известный
      ему шаблон, то примет решение о сконфигурированном charset согласно
      директивам AgentCharset. Если же шаблон не будет найден - сервер попытается
      найти имя charset в преффиксе имени виртуального сервера, к которому обращен
      запрос и/или в преффиксе затребованного URI.

      При установке в Off (это значение по-умолчанию) - наоборот.



      5. Некоторые рекомендации




      • Так как сервер наряду с согласованием charset использует и согласования
        по language, я рекомендую чтобы документы, содержащие не только
        английские символы (ISO8859-1) назывались в соответствии со своей языковой
        принадлежностью
        .
        Стандартным для Apache является добавление двухбуквенного
        кода в конец имени файла, например:

          index.html.ru
          index.html.en
          /cgi-bin/script.fr

        Если у вас есть документы, переведенные на разные языки, это также
        будет полезно клиентским программам для согласования language. Некоторые
        программы умеют в запросе посылать заголовки типа:

          GET / HTTP/1.0
          Accept-language: ru
          Accept-charset: windows-1251

        Кроме того, при использовании правильных языковых расширений файлов ваш
        сервер на русскоязычные документы будет выдавать charset=... и в случае
        теоретической возможности выдачи данного документа в другом charset,
        сервер будет добавлять заголовок Expires: current_date_time, что предупредит
        proxy сервера о нежелательности оседания данного документа в кэш proxy
        сервера. Не следует бояться того, что в таком случае придется переписывать
        перекрестные ссылки во всех документах. Это не так.
        Если на сервере лежит документ с именем file.html.ru, то на запрос клиента

        GET /file.html

        Сервер сможет найти соответствующий file.html.ru. Правда для этого
        необходимо при описании домашней директории сервера в файле conf/access.conf
        дополнить Options ... MultiViews
        . Например:

        <Directory /usr/local/etc/httpd/home>

        # This may also be "None", "All", or any combination of "Indexes",
        # "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".

        # Note that "MultiViews" must be named *explicitly* - "Options All"
        # doesn't give it to you (or at least, not yet).

        Options Indexes FollowSymLinks Includes MultiViews

        </Directory>

        Если на Вашем сервере большая часть документов русскоязычная,
        я рекомендую добавить в conf/srm.conf строку

        AddLanguage ru .html .ru

        При этом будет выдаваться charset=... для всех документов *.html,
        кроме документов, принадлежащих к другим языкам.

      • Если у Вас имеется возможность использовать различные IP адреса для
        разных виртуальных серверов, я также рекомендую это делать, т.к. по
        сравнению с разделением кодировок по портам это потребует меньше
        ресурсов от компьютера. Оптимальная на мой взгляд конфигурация следующая:

        • Базовый сервер www.company.name.ru сконфигурирован так, что он
          знает обо всех возможных charset и их псевдонимах. Кроме того он знает
          о всех User-agent и соответствующих им charsets по-умолчанию.
          Этот сервер в качестве NativeCharset должен иметь родную кодировку
          документов.
          Такой сервер сможет выполнить самый замысловатый запрос. Но будет
          противодействовать proxy серверам сохранять документы в кэш.
        • Виртуальные сервера, например windows-1251.company.name.ru или
          koi8-r.company.name.ru будут знать только об одной кодовой странице
          и всегда выдавать документы в ней вне зависимости от User-agent.
          Это не будет мешать proxy серверам сохранять такие документы.
        • В сочетании 2 предыдущих пунктов и правильно построив дерево
          документов можно будет удовлетворить любые потредности клиентов.

      • Если нет возможности использовать виртуальные сервера, я рекомендую
        выстроить дерево русскоязычных документов в отдельной директории,
        например /koi8-r/, в которой документы хранятся в native charset.
        После этого можно сделать символические ссылки типа:

        ln -s home_of_server/koi8-r home_of_server/windows-1251
        ln -s home_of_server/koi8-r home_of_server/ibm866

        или что-то подобное. Документы в этих директориях будут поступать к
        клиенту в кодировке, указанной в преффиксе.
        Надо помнить, что в этом случае перекрестные
        ссылки в таком дереве не должны содержать абсолютного пути, а указывать
        все время от текущего положения документа.
        Однако, если документ содержит в себе SSI, например:

        <!-#include virtual="/~dvk/cgi-bin/a.cgi"->

        результат работы a.cgi включенный сервером в документ будет также
        приведен к выбранному сервером charset, несмотря на то, что сам a.cgi
        не находится в дереве.


        Этот способ теперь также годится и для директорий пользователей,
        т.е. /~user/win/file.html будет выдаваться в windows-1251.



      Благодарности



      Я очень благодарен всем кто находил в текстах ошибки, высказывал
      свои замечания, предложения и суждения, особенно beta тестерам,
      которые нашли силы и время на эту кропотливую работу.
      Персональные благодарности (в алфавитном порядке):

      • Alexander Ermolaev <ae@mark-itt.ru>
      • Alex Tutubalin <lexa@lexa.ru>
      • Andrew Maltsev <am@f1.ru>
      • Andrey Gerasimov <andy@netclub.ru>
      • Dima Antipov <dima@elvis.msk.su>
      • Dmitry A.Deineka <axl@infocom.kharkov.ua>
      • Igor V. Semenyuk <iga@sovam.com>
      • Nickolay Saukh <nms@nns.ru>
      • Paul S. Hrobostov <hps@rp3.jetinf.ru>
      • Plechov P.Yu <lym@sunny.ccas.ru>
      • Prof. S.D.F. <sdf@lx.ispm.ac.ru>
      • Stanislav Sinyagin <stas@isf.ru>
      • Vladislav A. Chekalov <CHV@nhb.ru>

      и всем остальным, кого не упомянул.



      Apache HTTP server LICENSE





      /* ====================================================================
      * Copyright (c) 1995 The Apache Group. All rights reserved.
      *
      * Redistribution and use in source and binary forms, with or without
      * modification, are permitted provided that the following conditions
      * are met:
      *
      * 1. Redistributions of source code must retain the above copyright
      * notice, this list of conditions and the following disclaimer.
      *
      * 2. Redistributions in binary form must reproduce the above copyright
      * notice, this list of conditions and the following disclaimer in
      * the documentation and/or other materials provided with the
      * distribution.
      *
      * 3. All advertising materials mentioning features or use of this
      * software must display the following acknowledgment:
      * "This product includes software developed by the Apache Group
      * for use in the Apache HTTP server project (http://www.apache.org/)."
      *
      * 4. The names "Apache Server" and "Apache Group" must not be used to
      * endorse or promote products derived from this software without
      * prior written permission.
      *
      * 5. Redistributions of any form whatsoever must retain the following
      * acknowledgment:
      * "This product includes software developed by the Apache Group
      * for use in the Apache HTTP server project (http://www.apache.org/)."
      *
      * THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
      * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
      * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
      * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR
      * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
      * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
      * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
      * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
      * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
      * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
      * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
      * OF THE POSSIBILITY OF SUCH DAMAGE.
      * ====================================================================
      *
      * This software consists of voluntary contributions made by many
      * individuals on behalf of the Apache Group and was originally based
      * on public domain software written at the National Center for
      * Supercomputing Applications, University of Illinois, Urbana-Champaign.
      * For more information on the Apache Group and the Apache HTTP server
      * project, please see .
      *
      */







Комментарии
Анонимно
Войти под своим именем


Ник:
Текст сообщения:
Введите код:  

Загрузка...
Поиск:
добавить сайт | реклама на портале | контекстная реклама | контакты Copyright © 1998-2018 <META> Все права защищены