HTTP (HyperText Transfer Protocol) - прикладной клиент-серверный протокол типа "запрос-ответ" работающий поверх TCP (стандартный порт 80). Клиентом является броузер; сервером - WWW-сервер. В первой версии протокола (1.0) на одно TCP-соединение приходился один запрос и ответ, после чего соединение закрывалось. В настоящее время протокол позволяет выполнить несколько итераций в рамках одного соединения, что позволяет избежать накладных расходов на установление/закрытие соединений, снизить нагрузку на сеть и уменьшить время получения данных.
Последняя версия HTTP 1.1 описана в RFC-2616,2617.
Поля, помеченные звездочкой (*), присутствуют только, если в запросе использован метод POST или PUT (см. ниже).
Строка запроса имеет вид:
методURIпротокол/версия
Примеры:
GET / HTTP/1.1
POST /cgi-bin/sript?X=1&Y=a%20b HTTP/1.1
HEAD http://www.vvsu.ru/index.html HTTP/1.1
запрос заголовков документа, идентифицируемого указанным URI (аналогично GET, но само содержимое документа не возвращается).
POST
пересылка данных на сервер (используется при заполнении форм). URI в этом случае обычно идентифицирует CGI-скрипт, который будет обрабатывать присланные данные, и результат этой обработки будет возвращен в HTTP-ответе.
Существуют также методы PUT и DELETE, предназначенные для управления документами на сервере, но используются они крайне редко.
URI является указателем на запрашиваемый ресурс. При непосредственном обращении к серверу, содержащему запрашиваемый ресурс, URI имеет неполный вид (см. выше примеры GET и POST). При обращении через прокси-сервер URI должен быть полным (см. выше пример HEAD).
Заголовки, передаваемые вслед за строкой запроса, делятся на собственно заголовки запроса и на заголовки данных, передаваемых в запросе (разумеется, если такие данные присутствуют). Каждый заголовок начинается с новой строки и состоит из ключевого слова, за которым следует двоеточие, и данных, например:
Accept: text/html, text/plain;q=0.5
Порядок следования заголовков не имеет значения.
Ниже приведены примеры заголовков запроса (за полным списком и описаниями обращаться к RFC-2616). Заголовки данных рассмотрены ниже в отдельном пункте.
Host: athena.vvsu.ru
Доменное имя сервера, к которому производится обращение. Этот заголовок позволяет создавать на одном компьютере несколько виртуальных веб-серверов с различным содержимым; при этом запрошенный URI относится к пространству документов того виртуального сервера, имя которого указано в заголовке "Host:". Разумеется, имена всех виртуальных серверов должны быть прописаны в DNS как псевдонимы того компьютера, на котором они размещены. Заголовок "Host:" - единственный, являющийся обязательным в HTTP-запросе версии 1.1.
Accept: text/html, text/plain
MIME-типы данных, которые клиент согласен принять в ответ на свой запрос. Множественные значения перечисляются через запятую. Обычно броузер указывает среди значений "*/*", что означает, что он готов принять данные любого типа (в крайнем случае он предложит пользователю сохранить их на диск). Значение "*/*" также подразумевается, если заголовок отсутствует. О MIME-типах см. тему 4. Фактически, этот заголовок полезен, только если сервер может предоставить один и тот же документ в разных форматах (например, как текст, HTML-файл или документ Word).
Если сервер не может выдать документ ни в одной из приемлемых кодировок, то рекомендуется, чтобы он возвратил ошибку с кодом 406, однако допускается выдача запрошенного документа в какой-то другой кодировке.
Accept-Encoding: compress, gzip
Представление данных (в данном случае, сжатие), которое клиент понимает. Может быть использовано для запроса передачи документа в сжатом виде, если сервер это поддерживает.
Accept-Language: ru, en;q=0.2
Язык документа, который клиент согласен принять. Заголовок может быть использован, если сервер может предоставить один и тот же документ на разных языках.
User-Agent: Netscape/5.40; Solaris 2.5
Тип клиента (броузера).
Referer: http://athena.vvsu.ru/index.html
URL документа, в котором находилась ссылка на запрашиваемый документ. (То есть, если пользователь просматривает документ, находящийся по адресу http://athena.vvsu.ru/index.html, и выбирает в нем одну из ссылок, то броузер формирует запрос нового документа, на который указывает ссылка, а поле Referer в заголовке этого запроса имеет значение http://athena.vvsu.ru/index.html.) Обратите внимание, что написание заголовка противоречит правилам орфографии (по-английски правильно - "referrer").
Authorization: Basic d2VibWFzdGVyOnpycW1hNHY=
Этот заголовок используется в запросах, для выполнения которых сервер требует аутентификацию клиента. В заголовке указывается схема аутентификации (Basic - обычная аутентификация по имени пользователя и паролю), после чего следует строка "имя:пароль", преобразованная по алгоритму base64. Подробнее о процедуре аутентификации доступа к закрытым ресурсам см. ниже п. "Обработка запроса клиента".
Connection: Keep-Alive
Клиент прдлегает не закрывать TCP-соединение после обработки запроса, с тем чтобы это соединение могло быть использовано для последующих запросов и ответов на них. Если новые запросы не последовали в тчечение некоторого времени (несколько секунд), сервер закрывает соединение. Значение заголовка "Connection: close" указывает на то, что соединение будет закрыто после обработки данного запроса.
If-Modified-Since: Wed, 03 Nov 1999 19:43:11 GMT
Условный запрос (только метод GET). Сервер вернет документ, только если он был изменен после указанного времени. Иначе сервер вернет код 304 "Not Modified" (о кодах ответа сервера см. след. пункт) и содержимое документа передано не будет. Такой условный запрос используется, если броузер (или прокси-сервер) уже имеет в своем кэше копию запрашиваемого документа.
Range: bytes=0-499
Запрос части документа (только метод GET). Сервер возвращает код 206 "Partial content" (а не как обычно 200 "OK"), заголовок ответа и документа, а в качестве данных передается только указанная в запросе "Range:" часть документа (в данном примере: первые 500 байт). Другие примеры: "bytes=500-" - от 501 байта до конца документа, "bytes=-500" - последние 500 байт, "bytes=0-0,-1" - первый и последний байты. Сервер может проигнорировать заголовок "Range:", в этом случае он возвращает полный документ с кодом 200 "OK".
Поля, помеченные звездочкой (*), могут отсутствовать - это зависит от типа запроса. Например при запросе методом HEAD возвращаются только статусная строка с кодом 200, заголовки ответа и данных, а сами данные не передаются; а при условном запросе If-Modified-Since, в случае если документ не модифицирован, возвращаются только статусная строка с кодом 304 и заголовок ответа без заголовков данных и самих данных.
Статусная строка имеет вид:
протокол/версиякодстатусСтатус - текстовая строка, комментирующая код, предназначена для человека; программное обеспечение анализирует только числовое значение кода. Примеры статусных строк:
HTTP/1.1 200 OK
HTTP/1.1 304 Not Modified
Код ответа является трехзначным числом. Коды разделены по группам в зависимости от первой цифры:
1**
Промежуточные информационные сообщения (практически не используются).
2**
Успешная обработка запроса. Примеры:
200
OK - наиболее общий ответ: запрос обработан, запрошенный документ передан клиенту (или только его заголовки - в случае запроса HEAD).
206
Partial Content - клиенту передана часть документа в соответствии с заголовком "Range:", имевшимся в запросе.
3**
Для получения документа требуются дополнительные действия со стороны клиента. Примеры:
301
Moved Permanently - запрошенный документ перемещен. Новый URI документа возвращается в заголовке "Location:". В качестве данных возвращается краткий комментарий со ссылкой на новое расположение документа. В последующих запросах этого документа клиенту следует использовать новый URI. Как правило броузеры автоматически генерируют новый запрос с указанным URI при получении кода 301.
Сервер конфигурируется для возврата ответов с кодом 301 при реструктуризации его пространства документов - с тем, чтобы клиенты, использующие старые ссылки, перенаправлялись к новому расположению документов, а не получали ошибку 404 Not Found.
302
Found - запрошенный документ временно перемещен. Новый URI документа возвращается в заголовке "Location:". В качестве данных возвращается краткий комментарий со ссылкой на новое расположение документа. В последующих запросах этого документа клиенту следует использовать старый URI.
304
Not Modified - документ был запрошен с помощью условного GET-запроса и условие не выполнено (например, документ не был модифицирован с момента, указанного в запросе в заголовке "If-Modified-Since:"). Возвращаются только статусная строка и заголовки ответа, заголовки данных (документа) и сам документ не возвращаются.
4**
Ошибка клиента. Примеры:
400
Bad Request - ошибка в формате запроса.
401
Unauthorized - для доступа к ресурсу требуется аутентификация, но заголовок "Authorization:" либо отсутствует, либо содержит неприемлемые аутентификационные данные. Заголовок "WWW-Authenticate:" ответа в этом случае должен содержать информацию, необходимую для того, чтобы клиент определил, какая требуется аутентификация. Подробнее о процедуре аутентификации доступа к закрытым ресурсам см. ниже п. "Обработка запроса клиента".
403
Forbidden - север понял запрос, но намеренно отказался его выполнять. Аутентификация в этом случае не поможет. Причина отказа может быть передана в качестве данных HTTP-ответа. Если сервер не желает раскрывать причину отказа, он может использовать вместо кода 403 код 404.
404
Not Found - запрошенный ресурс не найден. Это наиболее общий ответ в случае невозможности передать клиенту запрошенный документ; при этом не делается никаких предположений о том, постоянно или временно ресурс недоступен, а также о причине его недоступности.
405
Method Not Allowed - в запросе использовался не разрешенный сервером метод (например, DELETE). Список разрешенных методов должен быть помещен в заголовке "Allow:" HTTP-ответа.
406
Not Acceptable - в заголовках "Accept..." клиент указал параметры перезентации документа, которые не могут быть выполнены сервером для данного документа (например, нет такой кодировки символов, какая указана в "Accept-Charset:").
410
Gone - аналогично 404 "Not Found", однако подразумевается, что документ существовал ранее, но умышленно удален навсегда (сделан недоступным). Полезно для временных презентаций, более не актуальных, для персональных страниц сотрудников, более не работающих в организации и т.п.
5**
Ошибка сервера. Примеры:
500
Internal Server Error - при обработке запроса произошла ошибка в программном обеспечении сервера. Типичный случай - ошибка в CGI-скрипте.
501
Not Implemented - сервер не обладает функциональностью, требуемой для выполнения запроса. Например, метод, указанный в запросе, не известен серверу.
502
Bad Gateway - сервер, действующий в качестве прокси-сервера, получил ошибочный (неадекватный) ответ от сервера, которому он перенаправил запрос клиента.
503
Service Unavailable - сервер временно не в состоянии обработать запрос (перегружен или находится на техобслуживании [maintanance]). Если известно время, через которое сервер вернется в рабочее состояние, оно может быть указано в заголовке "Retry-After:". Заметим, что в случае невозможности обслуживания запросов сервер не обязан выдавать ответ с кодом 503, а может просто отказывать в установлении TCP-соединения.
504
Gateway Timeout - сервер, действующий в качестве прокси-сервера, не получил за некоторое установленное время ответ от сервера, которому он перенаправил запрос клиента. Этот же код прокси-сервер должен возвращать, если произошел тайм-аут при опросе сервера DNS, однако некоторые существующие прокси-серверы возвращают при этом код 400 или 500.
Заголовки, передаваемые вслед за статусной строкой, делятся на собственно заголовки ответа и на заголовки данных, передаваемых в ответе (если такие заголовки требуются). Каждый заголовок начинается с новой строки и состоит из ключевого слова, за которым следует двоеточие, и данных. Порядок следования заголовков не имеет значения.
Ниже приведены примеры заголовков ответа (за полным списком и описаниями обращаться к RFC-2616). Заголовки данных рассмотрены ниже в отдельном пункте.
Server: Apache/1.3.6 (Unix) rus/PL28.16
Тип WWW-сервера, его версия, дополнительные модули и подобная информация.
Date: Mon, 13 Mar 2000 07:38:48 GMT
Время ответа.
Accept-Ranges: bytes
Сервер может выдавать документ по частям (по байтам).
WWW-Authenticate: Basic realm="SysAdmin"
Этот заголовок возвращается с ответом 401 Authorization Required, в котором указана схема аутентификации и ее контекст ("System Administration"). Последнее - комментарий для пользователя, который броузер показывает в окне запроса имени и пароля.
Location: http://new.url.com/
Новый URL документа, возвращенный вместе с ответом типа 301 Moved Permanently, 302 Found.
Connection: close
См. заголовок Connection в заголовках HTTP-запроса выше.
Allow: GET, HEAD, POST
Перечисляются HTTP-методы, поддерживаемые сервером. Отправляется в ответ на запрос, содержавший недопустимый метод. Ответ сервера имеет кодом 501 Not Implemented).
Заголовки данных описывают данные, посылаемые в HTTP-запросе или ответе. В запросе обычно посылаются данные заполненных форм (метод POST). Заголовки данных следуют в заголовочной части HTTP-ответа или запроса вместе с заголовками ответа или запроса; порядок следования заголовков различныз типов не определен. Сами данные всегда отделяются от заголовочной части пустой строкой.
Ниже приведены примеры заголовков данных (за полным списком и описаниями обращаться к RFC-2616).
Content-Type: text/html; charset=koi8-r
MIME-тип содержимого, дополнительным параметром указывается, например, кодировка символов. Подробнее о типах MIME см. тему 4. У данных заполненных форм, отправляемых в HTTP-запросе методом POST заголовок "Content-Type:" имеет значение "application/x-www-form-urlencoded". Подробнее об этом см. тему 6 "CGI".
Last-Modified: Sat, 11 Dec 1999 11:21:19 GMT
В НТТP-ответах: время последней модификации запрошенных данных на сервере.
Expires: Mon, 14 Mar 2000 07:38:48 GMT
В HTTP-ответах: время истечения срока годности данных (до каких пор они могут храниться в кэшах прокси-сервера и(или) броузера). Для того, чтобы документ не кэшировался, нужно поставить время, совпадающее с временем в поле Date HTTP-ответа.
Заголовок указывает представление данных (в данном случае - сжатие с помощью программы gzip) - то есть дополнительное преобразование, произведенное над данными перед передачей. Если данные передаются "как есть", этот заголовок отсутствует.
Content-Range: 0-294/1234
При передаче документа по частям (см. заголовок "Range:" HTTP-запроса) - номера первого и последнего байтов и общая длина документа. В данном случае - первые 295 из 1234 байт.
Apache - самый распространенный в Интернет WWW-сервер. Программа распространяется бесплатно в исходных текстах для Unix и Windows; проект поддерживается организацией Apache Software Foundation. Кроме собственно WWW-сервера ASF поддерживает еще ряд проектов, связанных с Apache, например, интеграция Apache и Перл (модуль mod_perl, см. ниже), проект Java-Apache.
Одним из основных достоинств Apache является его модульность и открытость API (Application Programming Interface), что позволяет
подключать только необходимые модули, гибко регулируя соотношение между функциональностью и размером программы сервера;
создавать дополнительные модули (яркий пример - модуль mod_charset, обеспечивающий обслуживание кириллических кодировок - проект Russian Apache);
изменять стандартное поведение сервера на той или иной стадии обработки запроса (например, производить аутентификацию не по файлу с паролями, а путем запроса в базу данных; подробнее см. ниже п. "Perl API и модуль mod_perl").
Общая схема работы Apache (на примере версии для Unix) такова:
Запуск сервера - этот процесс запускается с большими привилегиями (например, root - для доступа к стандартному HTTP-порту 80). Непосредственно запросы клиентов этим процессом не обслуживаются; он управляет работой сервера. Запустившись, сервер производит разбор директив в конфигурационном файле (файлах), открывает лог-файлы, перенаправляет вывод стандартной ошибки в файл, указанный директивой ErrorLog. Этими же лог-файлами будут пользоваться все порожденные процессы.
Инициализация модулей.
Запуск дочерних процессов - главный процесс ветвится с помощью вызова fork, порождая несколько дочерних процессов, которые собственно и будут обслуживать запросы клиентов. В целях безопасности порожденные процессы запускаются с низким уровнем привилегий (по умолчанию - как пользователь nobody). Число порождаемых процессов определяется директивой StartServers.
Запрос, поступающий от клиента, отправляется на обработку одному из дочерних процессов. Цикл обработки запроса является основным смыслом деятельности сервера, он разобран отдельно в следующем пункте. После завершения обработки запроса процесс ожидает поступления следующего запроса. При достижении максимального числа обработанных запросов (директива MaxRequestsPerChild) дочерний процесс прекращает свою работу.
Главный процесс осуществляет мониторинг дочерних процессов. Если число процессов падает ниже установленного директивой MinSpareServers, то запускаются дополнительные дочерние процессы.
При одновременном поступлении большого числа запросов главный процесс также запускает дополнительные процессы, но после прохождения пика лишние процессы будут удалены так, чтобы общее число ожидающих запроса процессов не превышало установленного директивой MaxSpareServers. Максимальное количество порожденных процессов определяется директивой MaxClients, что и является ограничением на число одновременно обслуживаемых сервером запросов.
При получении команды "stop" (сигнал TERM) главный процесс останавливает дочерние процессы, а потом выходит сам. При получении команды "restart" (сигнал HUP) главный процесс останавливает дочерние процессы, но сам не выходит; заново производится разбор конфигурационных директив и инициализация модулей, потом запускаются дочерние процессы. При получении команды "graceful" (сигнал USR1) действия сервера аналогичны команде "restart", однако дочерние процессы не прерываются принудительно, а им дается возможность обслужить текущий запрос (если таковой имеется) и только после этого выйти. Сигналы должны отпраляться только главному процессу, его идентификатор содержится в файле, указанном директивой PidFile; предпочтительнее всего пользоваться утилитой apachectl (см. ниже п. "Установка и работа с сервером").
Конфигурирование сервера выполняется путем внесения директив в файл httpd.conf, расположенный в каталоге conf дерева установки сервера (см. ниже п. "Установка и работа с сервером") и считываемый сервером при запуске (перезапуске). Директивы могут находиться также и в других файлах, которые подключаются с помощью директивы "Include" в файле httpd.conf.
Обычно Apache поставляется с файлом httpd.conf, уже содержащим примерную рабочую конфигурацию, причем каждая директива снабжена подробным комментарием на английском языке.
Существует несколько контекстов конфигурирования, в которых могут применяться те или иные директивы (для каждой директивы в справочной документации указываются все контексты, где она может быть применена):
server config - директива применяется при конфигурировании основного сервера, т.е. относится ко всем поступающим запросам или ко всему серверу как таковому. Все директивы, не попадающие в ниже описанные контексты, находятся к контексте server config.
virtual host - директива применяется внутри раздела, определяемого директивой
<VirtualHost имя_виртуального_сервера>
.....
#директивы, находящиеся здесь относятся только к запросам, в
#заголовке Host которых указан данный виртуальный сервер
.....
</VirtualHost>
Сама по себе директива VirtualHost может находиться только в контексте server-config.
directory - директива применяется внутри разделов типа
<Directory путь_к_каталогу>
....
#директивы, находящиеся здесь относятся только к запросам файлов,
#находящихся в указанном каталоге (или его подкаталогах); путь
#отсчитывается от каталога, указанного директивой DocumentRoot
....
</Directory>
<Location начало_URI>
....
#директивы, находящиеся здесь относятся только к запросам URI, #начинающихся со строки, указанной в директиве Location
....
</Location>
<Files рег._выражение_для_файлов>
....
#директивы, находящиеся здесь относятся только к запросам файлов, #имена которых удовлетворяют указанному регулярному выражению
....
</Files>
Сами по себе директивы Location, Directory и Files могут находиться как в контексте server config, так и в контексте virtual host. Более того, директива Files может находиться внутри раздела Directory, а также в контексте htaccess.
htaccess - директива применяется в файле .htaccess (имя файла начинается с точки), расположенном в каком-либо каталоге внутри дерева документов сервера. Директива срабатывает для всех запросов файлов из этого каталога и его подкаталогов (если там не находится другой файл .htaccess - в этом случае последний будет иметь приоритет). Директивы файла .htaccess имею приоритет над директивами раздела <Directory ...>...</Directory>, относящимися к тому же каталогу.
Если одна и та же директива в разных контекстах имеет разные значения, то действует значение в наиболее узком применимом к данному запросу контексте.
На стадии разбора URI сервер определяет файл, который был запрошен клиентом. Если на стадии определения MIME-типа документа было обнаружено, что файл должен быть интерпретирован как исполнимая программа, то для генерации ответа Apache запускает этот файл, в соответствии со спецификацями интерфейса CGI.
В Apache реализован механизм SSI, который представляет собой разбор HTML-документов на стороне сервера с целью обнаружения в документе и выполнения директив, добавляющих в документ дополнительную информацию. Директивы могут вставлять в HTML-документ другой HTML-файл или результат работы CGI-программы; вставлять характеристики документа (размер файла, дату последней модификации),
текущее время и т.п.
Модуль mod_charset производит переобразование кириллических документов в кодировку, требуемую клиенту. При этом сначала рассматриваются заголовки запроса (Accept-Charset), потом, если требуемую кодировку определить не удалось, - конфигурационные директивы модуля mod_charset (CharsetSelectionOrder и др.),
а в случае неудачи документ возвращается в кодировке, определенной директивой CharsetDeafult.
Кодировка, в которой документ хранится на диске, задается директивой CharsetSourceEnc, которую можно применять во всех конфигурационных контекстах.
Модуль mod_perl реализует интерфейс API к серверу Apache на языке Perl, что позволяет модифицировать поведение сервера на любой фазе обработки запроса в соответствии с конкретными требованиями пользователя (например производить аутентификацию не по файлу с именами пользователей и их паролями, а по базе данных). Кроме того, модуль позволяет существенно ускорить исполнение CGI-скриптов, написанных на Perl: теперь не запускается отдельного процесса Perl-интепретатора для каждого скрипта; интерпретатор находится внутри процесса веб-сервера; более того, однажды исполненный скрипт кэшируется в компилированном виде.
Модуль mod_jserv является интерфейсом сервера Apache к исполнителю сервлетов (servlet engine), написанных на языке Java.
Интерфейс jserv сходен по функциональности с CGI, но обладает повышенной гибкостью.
Модуль mod_ssl реализует в Apache слой SSL, осуществляющий шифрование всего потока данных между клиентом и сервером. Для всех остальных частей веб-сервера модуль mod_ssl является прозрачным.
Для работы в этом режиме, требуется броузер, поддерживающий мехнизм SSL (этому условию удовлетворяют все современные распространенные броузеры).
Установка сервера осуществляется в следующей последовательности:
распаковать дистрибутив Apache;
если требуется установка дополнительных модулей (например, mod_perl, mod_jserv, mod_ssl) - распаковать их дистрибутивы в том же каталоге; при конфигурировании сервера следовать дополнительным инструкциям по установке модулей, приведенных в их дистрибутивах;
сконфигурировать исходный код сервера командой
./configure --prefix=/путь/установки/Apache
(возможны различные дополнительные ключи, свзяанные с добавлением или удалением модулей);
скомпилировать и установить сервер командами "make" и "make install".
Все компоненты сервера устанавливаются в дерево, корнем которого является каталог, указанный в параметре "--prefix"; вне этого дерева никакие компоненты программы не располагаются (это может быть неверно для дополнительных модулей - см. документацию к этим модулям). Этот же каталог должен быть значением конфигурационной директивы ServerRoot. Конфигурационный файл httpd.conf находится в каталоге ServerRoot/conf.
Запуск, перезапуск и останов сервера выполняются командой ServerRoot/bin/apachectl с параметрами start, stop, restart, graceful.
1. Запустить на своем компьютере (Unix) анонимный FTP-сервер.
Создать каталог с "невидимым" содержимым для входящих файлов.
2. Сконфигурировать на своем компьютере WWW-сервер Russian
Apache для перекодировки кириллицы по номеру порта (осуществлять
перекодировку в win, koi, iso, dos и транслитерацию). В дереве документов организовать два каталога: в одном хранить документы в оригинальной кодировке win, в другом - в koi. Обеспечить разумный порядок определения выходной кодировки при обращении на стнадартный порт 80.
3. На один из каталогов назначить авторизованный доступ: с "разрешенных" компьютеров - доступ открытый; со всех остальных - по паролю.