Коды ответов (ошибок) HTTP сервера

Коды ответов (ошибок) HTTP сервера

При любом HTTP запросе сервер сначала возвращает код ответа на HTML запрос. Проанализировав этот ответ можно сделать вывод о том, был ли запрос выполнен успешно, или в процессе обработки запроса произошла ошибка.

Коды ответа HTTP сервера могут принадлежать следующим группам:
1xx — Информационный ответ
2xx — Успешная обработка запроса
3xx — Переадресация (редирект)
4xx — Неполный запрос к серверу
5xx — При обработке запроса произошла ошибка

Естественно, что кодов ответа в каждой группе не по 100. Браузер (клиент IE, Opera, Mozilla и т.д.), получая от сервера тот или иной код, сам решает как его интерпретировать. Если код клиенту неизвестен, то как минимум он может определить диапазон кода и повести себя соответствующим образом.

Информационные ответы

100 Continue
Часть запроса принята. Как правило это занчит, что можно отправлять следующую часть запроса.

101 Switching Protocols
Сервер производит переключение протоколов в соответствии с заголовком Upgrade.

Успешная обработка запроса

200 OK
Запрос обработан успешно.

201 Created
Данный код используется когда происходит создание нового URI. Вместе с кодом сервер посылает заголовок Location с адресом нового URI.

202 Accepted
Запрос принят и обрабатывается. В теле ответа как правило содержится дополнительная информация.

203 Non-Authoritative Information
Ответ означает, что информация получена из ненадежного источника (например, с другого сервера).

204 No Content
Запрос обработан, но в ответ ничего не возвращается. Как правило используется если в ответ на запрос не нужно обновлять содержимое документа.

205 Reset Content
Означает, что содержимое документа должно быть сброшено в начальное состояние. Обычно используется при очистке форм ввода данных..

206 Partial Content
При данном ответе возвращается лишь часть данных. Обычно используется если клиент запросил часть данных с использованием заголовка Range.

Переадресация

300 Multiple Choices
Означает, что существует несколько вариантов запрашиваемой страницы. Например, сайт, переведенный на несколько языков.

301 Moved Permanently
Данный ответ означает, что данный документ был перемещен и клиенту следует изменить все ссылки на данный документ его новым местоположением.

302 Moved Temporarily
Документ временно перемещен в другое место.

303 See Other
Данный документ можно найте по другим ссылкам. Список ссылок передан в теле ответа.

304 Not Modified
Данный код ответа возвращается если был запрос lf-Modified-Since, и документ не изменялся с указанной даты.

305 Use Proxy
Доступ к документу должен осуществляться через proxy-сервер, адрес которого указан в Location.

Неполные запросы клиента

400 Bad Request
Ошибка в строке запроса.

401 Unauthorized
Ответ означает, что пользователь не имеет достаточных прав для просмотра документа.

402 Payment Required
Данный код зарезервирован на будущее. Видимо будет означать, что запрошенный документ является платным ресурсом.

403 Forbidden
Запрос не будет выполнен по какой-либо причине.

404 Not Found
Запрашиваемого документа нет на сервере.

405 Method Not Allowed
Означает, что метод, используемый клиентом, не поддерживается.

406 Not Acceptable
Ресурс существует, но не в той форме, что клиент запросил. Например, может различаться язык документа.

407 Proxy Authentication Required
Для Proxy-сервера необходима авторизация.

408 Request Time-out
Сервер разорвал соединение из-за превышенного таймаута.

409 Conflict
Запрос конфликтует с другим запросом.

410 Gone
Данный код означает, что документ был удален с сервера.

411 Length Required
Пропущено необходимое поле в заголовке запроса Content-Length.

412 Precondition Failed
Условие указанное в заголовке не выполняется.

413 Request Entity Too Large
Слишком большое тело запроса.

414 Request-URI Too Long
Слишком длинный URI в запросе.

415 Unsupported Media Type
Сервер не поддерживает указанный формат данных.

Ошибки сервера

500 Internal Server Error
Внутренняя ошибка сервера. Например, ошибка при выполнении скрипта.

501 Not Implemented
Недопустимое действие.

502 Bad Gateway
Недопустимый ответ с другого ресурса.

503 Service Unavailable
Данный код означает, что указанный сервис временно недоступен.

504 Gateway Time-out
Превышен таймаут ожидания от другого ресурса

505 HTTP Version not supported
Данная версия протокола HTTP не поддерживается сервером.

By sysadmin on 28.04.2009 | Development, FreeBSD, Linux, Windows
Метки: , , , ,

Умное Кеширование и Версионность в Javascript/CSS

Подключая внешние CSS и Javascript, мы хотим снизить до минимума лишние HTTP-запросы.

Для этого .js и .css файлы отдаются с заголовками, обеспечивающими надежное кеширование.

Но что делать, когда какой-то из этих файлов меняется в процессе разработки? У всех пользователей в кеше старый вариант — пока кеш не устарел, придет масса жалоб на сломанную интеграцию серверной и клиентской части.

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

Простое кеширование ETag

Самый простой способ кеширования статических ресурсов — использование ETag.

Достаточно включить соответствующую настройку сервера (для Apache включена по умолчанию) — и к каждому файлу в заголовках будет даваться ETag — хеш, который зависит от времени обновления, размера файла и (на inode-based файловых системах) inode.

Браузер кеширует такой файл и при последующих запросах указывет заголовок If-None-Match с ETag кешированного документа. Получив такой заголовок, сервер может ответить кодом 304 — и тогда документ будет взят из кеша.

Выглядит это так:

Первый запрос к серверу (кеш чистый)

GET /misc/pack.js HTTP/1.1
Host: javascript.ru

Вообще, браузер обычно добавляет еще пачку заголовоков типа User-Agent, Accept и т.п. Для краткости они порезаны.

Ответ сервераСервер посылает в ответ документ c кодом 200 и ETag:

HTTP/1.x 200 OK
Content-Encoding: gzip
Content-Type: text/javascript; charset=utf-8
Etag: "3272221997"
Accept-Ranges: bytes
Content-Length: 23321
Date: Fri, 02 May 2008 17:22:46 GMT
Server: lighttpd

Следующий запрос браузера
При следующем запросе браузер добавляет If-None-Match: (кешированный ETag):

GET /misc/pack.js HTTP/1.1
Host: javascript.ru
If-None-Match: "453700005"

Ответ сервера
Сервер смотрит — ага, документ не изменился. Значит можно выдать код 304 и не посылать документ заново.

HTTP/1.x 304 Not Modified
Content-Encoding: gzip
Etag: "453700005"
Content-Type: text/javascript; charset=utf-8
Accept-Ranges: bytes
Date: Tue, 15 Apr 2008 10:17:11 GMT

Альтернативный вариант — если документ изменился, тогда сервер просто посылает 200 с новым ETag.

Аналогичным образом работает связка Last-Modified + If-Modified-Since:

1. сервер посылает дату последней модификации в заголовке Last-Modified (вместо ETag)
2. браузер посылает дату закешированной версии в заголовке If-Modified-Since(вместо If-None-Match)
3. Если скрипт не изменился — ответ содержит только код 304

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

Умное кеширование. Версионность

Общий подход для версионности — в двух словах:

1. Во все скрипты добавляется версия (или дата модификации). Например, http://javascript.ru/my.js превратится в http://javascript.ru/my.v1.2.js
2. Все скрипты жестко кешируются браузером
3. При обновлении скрипта версия меняется на новую: http://javascript.ru/my.v2.0.js
4. Адрес изменился, поэтому браузер запросит и закеширует файл заново
5. Старая версия 1.2 постепенно выпадет из кеша

Дальше мы разберем, как сделать этот процесс автоматическим и прозрачным.

Жесткое кеширование

Жесткое кеширование — своего рода кувалда которая полностью прибивает запросы к серверу для кешированных документов.

Для этого достаточно добавить заголовки Expires и Cache-Control: max-age.

Например, чтобы закешировать на 365 дней в PHP:

header("Expires: ".gmdate("D, d M Y H:i:s", time()+86400*365)." GMT");
header("Cache-Control: max-age="+86400*365);

Или можно закешировать контент надолго, используя mod_header в Apache:

Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT"
Header add "Cache-Control" "max-age=315360000"

Получив такие заголовки, браузер жестко закеширует документ надолго. Все дальнейшие обращения к документу будут напрямую обслуживаться из кеша браузера, без обращения к серверу.

Большинство браузеров (Opera, Internet Explorer 6+, Safari) НЕ кешируют документы, если в адресе есть вопросительный знак, т.к считают их динамическими. Именно поэтому мы добавляем версию в имя файла. Конечно, с такими адресами приходится использовать решение типа mod_rewrite, мы это рассмотрим дальше в статье.P.S А вот Firefox кеширует адреса с вопросительными знаками.

Автоматическое преобразование имен

Разберем, как автоматически и прозрачно менять версии, не переименовывая при этом сам файлы.

Имя с версией -> Файл

Самое простое — это превратить имя с версией в оригинальное имя файла.

На уровне Apache это можно сделать mod_rewrite:

RewriteEngine on
RewriteRule ^/(.*\.)v[0-9.]+\.(css|js|gif|png|jpg)$    /$1$2    [L]

Такое правило обрабатывает все css/js/gif/png/jpg-файлы, вырезая из имени версию.

Например:

/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js

Но кроме вырезания версии — надо еще добавлять заголовки жесткого кеширования к файлам. Для этого используются директивы mod_header:

Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT"
Header add "Cache-Control" "max-age=315360000"

А все вместе реализует вот такой апачевый конфиг:

RewriteEngine on
# убирает версию, и заодно ставит переменную что файл версионный
RewriteRule ^/(.*\.)v[0-9.]+\.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]
 
# жестко кешируем версионные файлы
Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" env=VERSIONED_FILE
Header add "Cache-Control" "max-age=315360000" env=VERSIONED_FILE

Из-за порядка работы модуля mod_rewrite, RewriteRule нужно поставить в основной конфигурационный файл httpd.conf или в подключаемые к нему(include) файлы, но ни в коем случае не в .htaccess, иначе команды Header будут запущены первыми, до того, как установлена переменная VERSIONED_FILE. Директивы Header могут быть где угодно, даже в .htaccess — без разницы.

Автоматическое добавление версии в имя файла на HTML-странице

Как ставить версию в имя скрипта — зависит от Вашей шаблонной системы и, вообще, способа добавлять скрипты (стили и т.п.).

Например, при использовании даты модификации в качестве версии и шаблонизатора Smarty — ссылки можно ставить так:

<link href="{version src='/css/group.css'}" rel="stylesheet" type="text/css" />

Функция version добавляет версию:

function smarty_version($args){
 
  $stat = stat($GLOBALS['config']['site_root'].$args['src']);
  $version = $stat['mtime'];
 
  echo preg_replace('!\.([a-z]+?)$!', ".v$version.\$1", $args['src']);
}

Результат на странице:

<link href="/css/group.v1234567890.css" rel="stylesheet" type="text/css" />

Отпимизация

Чтобы избежать лишних вызовов stat, можно хранить массив со списком текущих версий в отдельной переменной

$versions['css'] = array(
  'group.css' => '1.1',
  'other.css' => '3.0',
}

В этом случае в HTML просто подставляется текущая версия из массива.

Можно скрестить оба подхода, и выдавать во время разработки версию по дате модификации — для актуальности, а в продакшн — версию из массива, для производительности.

Применимость

Такой способ кеширования работает везде, включая Javascript, CSS, изображения, flash-ролики и т.п.

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

By sysadmin on 25.02.2009 | Development
Метки: , , , , , ,

Пошаговая настройка SSL для Apache

Перевод статьи «Step by Step: Configuring SSL Under Apache» автора Juliet Kemp.

Вступление

Если у вас безопасный веб-сервер, пользователи, волнующиеся за безопасность своих данных, могут быть уверены, что запросы зашифрованы, поэтому их данные в безопасности. Лучшим путем для этого является использование Apache 2, лидирующего веб-сервера под Linux и Secure Sockets Layer, протокол безопасной передачи данных. Transport Layer Security (TLS) является развитием SSL, но они работают практически одинаково. Я буду ссылаться только на SSL.

SSL — протокол для безопасной передачи зашифрованных данных между веб-браузером и веб-сервером. В большинстве случаев, аутентификацию проходит сервер, что позволяет клиенту быть уверенным в том, что сервер является требуемым ему, а не наоборот. Как бы то ни было, когда соединение устанавливается, обе стороны находятся в безопасности, так как только клиент и сервер имеют доступ к ключу. Это работает в течении многих запросов, сервер не интересует, кем является клиент так долго, сколько он остается тем же клиентом на протяжении запроса. Если вас волнует аутентификация клиента, есть возможность использовать клиентские SSL сертификаты (или htaccess, Kerberos или другие, близкие к ним методы), но это не будет рассматриваться в этой статье.

Будучи на стороне клиента, вас волнует, тому ли человеку (серверу) вы посылаете какие-либо личные данные, которые хотите зашифровать. Поэтому сервер, а не клиент, аутентифицируется. Вас также беспокоит участие третей стороны в доступе к вашим данным в том виде, каком вы их посылаете. SSL предоставляет оба этих вида безопасности.

Протокол SSL работает следующим образом:

1. Клиент подключается к веб-серверу и дает список доступных кодов.

2. Сервер берет наиболее устойчивый код, который поддерживает и он, и клиент, и посылает сертификат со своим именем и ключ кодирования, подписанный доверенным Удостоверяющим Центром (Certificate Authority, далее — CA), таким как Verisign.

3. Клиент проверяет сертификат с помощью CA. На практике, хранят набор CA локально, поэтому это может быть сделано без контакта в реальном времени с CA, и поэтому более быстро.

4. Клиент посылает назад случайное число, зашифрованное с помощью публичного ключа сервера. Только клиент знает это число, и только сервер может его расшифровать (используя личный ключ); вот где реализуется безопасность от участия третей стороны.

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

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

Настройка Apache для работы с SSL проста, но есть несколько необходимых шагов. Эта статья рассказывает, как получить сертификат, подписанный CA и как скомпилировать и настроить Apache для работы с SSL. Я использую Apache 2 с mod_ssl. ApacheSSL (реализация Apache с возможностями SSL) также доступен, но сейчас он уже устарел; mod_ssl намного лучше.

Создание сертификата.

Первый шаг — создание сертификата. Вы можете создать сертификат с паролем или без него. Главным неудобством использования пароля является тот факт, что он должен быть введен каждый раз при старте сервера. Поэтому он не может запускаться без присмотра или автоматически при загрузке, например, после выключения электричества. В зависимости от ваших установок, это может быть значимым фактом для вас, или нет.

Теоретически, преимуществом использования пароля являтся повышение защиты. Хотя, на практике пароли не дает такой большой защиты. Если кто-то сможет прочитать или скопировать приватный ключ, значит, у него уже есть доступ к системе и возможность получить пароль, например, используя такую программу, как кейлоггер. Пароль защитит от скрипт-кидди, но не от серьезного взломщика. Возможно, для большинства людей нет смысла его использовать.

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

openssl req -new -x509 -days 365 -sha1 -newkey rsa:1024 \
 
-nodes -keyout server.key -out server.crt \
 
-subj '/O=Company/OU=Department/CN=www.example.com'

Давайте рассмотрим опции более подробно:

— -x509 означает, что сертификат обязателен, правильнее, чем просто запрос сертификата (смотри ниже)

— -days 365 устанавливает время истечения сертификата, равное году. Вы можете увеличить этот срок. Запомните дату истечения срока, чтобы обновить её при необходимости.

— -sha1 указывает, что будет использован SHA1 для шифрования.

— rsa:1024 делает ключ 1024 битным RSA.

— -nodes указывает отсутствие пароля.

— -keyout и -out указывают, где хранить сертификат и ключ. Ключ должен быть доступен для чтения только для root; сертификат может быть доступен для чтения для world, но должен быть доступным для чтения пользователю, который запускает Apache.

— -subj устанавливает имя компании, имя отделения компании и адрес веб-сайта. Если вы это пропустите, вас попросят это сделать. CN должен совпадать с адресом сайта, иначе сертификат не будет соответствовать, и пользователи будут получать предупреждение при подключении. Убедитесь, что вы не запрашиваете пароль.

Проблема с использованием сертификата, подписанного самостоятельно для сервера, работающего в реальном времени, заключается в том, что любой браузер, работающий с сайтом, не будет признавать сертификат правильным. Это значит, что пользователя будут запрашивать о подтверждении сертификата. Очевидно, что в большинстве случаев это не является оптимальным решением. Хотя, это нормально для целей теста, а для небольших локальных сетей было бы плохим вариантом платить за сертификат от CA.

Не смотря на это, безусловно, лучше использовать сертификат, подписанный доверенным Удостоверяющим Центром, таким как Verisign (который имеет наибольший охват рынка), или меньшей организацией. Большинство браузеров уже имеют набор предустановленных сертификатов, заверенных CA, которые верифицируют сертификат вашего веб-сервера при подключении клиента. Это уменьшает количество трудностей для конечного пользователя и удостоверяет законность вашего сайта.

Чтобы получить сертификат, подписанный CA, прежде всего вы должны создать криптографическую пару и запрос сертификата:

openssl req -new -sha1 -newkey rsa:1024 -nodes \ 
 
-keyout server.key -out www.example.com.csr \ 
 
-subj '/O=Company/OU=Department/CN=www.example.com'

Этот пример работает так же, как и предыдущий, но на этот раз мы не используем опцию -x509. Выполнение этой команды приведет к генерации ключа и запроса сертификата, но не самого сертификата. Если вы ввели CN и так далее, вы не должны вводить адрес e-mail или пароль.

Ключ сервера (файл server.key, который, опять же, должен быть доступен для чтения только для root) остается на вашем веб-сервере; запрос (файл www.example.com.csr) отправляется в CA. Вы можете назвать файл запроса так, как вам вздумается, но назвав его по своему доменному имени, вы упростите задачу для CA.

Следующей стадией будет послать этот файл www.example.com.csr в CA, с вашей оплатой. Они должны вернуть его достаточно быстро, если вы предоставили всю требуемую информацию в вашем запросе. Выбранный вами CA объяснит их действия на своем сайте. Вам может понадобиться поменять формат файла на PEM, но, в случае Verisign, этого делать не придется.

Когда вы получите файл назад в PEM формате, переименуйте его в server.crt (это не является строгой необходимостью, но соответствует условиям Apache) и проверьте его:

    openssl verify -CAfile /path/to/trusted_ca.crt \
 
		-purpose sslserver server.crt

Затем проверьте, что результат выполнения этих двух команд одинаков, т.е., что сертификат соответствует приватному ключу:

    openssl x509 -noout -modulus -in server.pem | openssl sha1
 
    openssl rsa -noout -modulus -in server.key | openssl sha1

Теперь установите ваш ключ (сгенерированный выше как server.key) и сертификат (server.crt) в /etc/apache2/ssl или предпочитаемый вами каталог настроек, если он другой. Как указано выше, очень важно убедиться, что server.key доступен для чтения только для root, в то время как сертификат сервера может быть доступен для чтения для world, но принадлежать и быть доступным для записи только для root.

Компиляция Apache с SSL.

Итак, ваш сертификат сгенерирован. Теперь вам надо настроить свой сервер для его использования.

Для подавляющего большинства людей, лучшим способом установить и управлять Apache2 — модули, полученные через менеджер пакетов вашего дистрибутива. Apache2 из Debian идет вместе с модулем SSL, но он не включен по умолчанию. Для его включения вы должны выполнить команду: a2enmod ssl и перезапустить веб-сервер.

Чтобы сделать это, добавьте строчку

    Include /etc/apache2/mod_ssl.conf

в ваш /etc/apache2/apache2.conf (этот файл может также называться httpd.conf). Вы должны исправить её, обозначив соответствующее расположение файла mod_ssl.conf. Затем перезапустите веб-сервер.

Если вы хотите скомпилировать Apache2 из исходных кодов, в зависимости от того, какие установки вы до этого использовали, вы можете уже иметь или не иметь поддержку SSL. Проверьте это командой apache2 -l. Если перекомпиляция понадобится, запустите ./configure со всеми опциями, которые вы использовали до этого, добавив к ним —enable-ssl и —enable-setenvif (последняя нужна для совместимости с капризами Internet Explorer). Затем установите его как обычно, с помощью make;make install и проверьте правильность прав доступа.

Настройка Apache с SSL.

Следующим шагом будет настройка Apache2. Следующие инструкции приведут к запуску сервера как безопасного (порт 443) и как обычного веб-сервера (порт 80). Прежде всего, вам надо настроить сервер на принятие запросов на оба порта. Или отредактируйте /etc/apache2/ports.conf (в Debian, это входит в apache2.conf), или отредактируйте /etc/apache2/apache2.conf, включив строки:

Listen 80
 
Listen 443

Затем отредактируйте /etc/apache2/sites-enabled/yoursite для использования настроек SSL. Разделение настроек обычного и безопасного сервера с помощью VirtualHost — простейший способ из соображений условий эксплуатации. Любые настройки вне секций VirtualHost (например, установка ServerAdmin) будут применяться для обоих (и любых других) VirtualHost. Добавьте следующий текст в файл конфигурации:

# =================================================
 
# SSL/TLS settings
 
# =================================================
 
NameVirtualHost *:443
 
    DocumentRoot "/local/www/ssl_html"
 
    SSLEngine on
 
    SSLOptions +StrictRequire
 
        SSLRequireSSL
 
    SSLProtocol -all +TLSv1 +SSLv3
 
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
 
    SSLRandomSeed startup file:/dev/urandom 1024
 
    SSLRandomSeed connect file:/dev/urandom 1024
 
    SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
 
    SSLSessionCacheTimeout 600    
 
    SSLCertificateFile /etc/apache2/ssl/server.crt
 
    SSLCertificateKeyFile /etc/apache2/ssl/server.key
 
    SSLVerifyClient none
 
    SSLProxyEngine off
 
        AddType application/x-x509-ca-cert      .crt
 
        AddType application/x-pkcs7-crl         .crl
 
    SetEnvIf User-Agent ".*MSIE.*" \  
 
      nokeepalive ssl-unclean-shutdown \  
 
      downgrade-1.0 force-response-1.0

Несколько замечаний об этой конфигурации:

— SSLEngine должен быть включен, обозначая, что сервер использует SSL.

— DocumentRoot устанавливает корневой каталог виртуального хоста. Это значит, что вы можете отделять безопасное содержимое от обычного.

— SSLRequireSSL запрашивает использование SSL (на этом виртуальном сервере), то есть, пользователь не может подключиться к этому виртуальному хосту с помощью обычного HTTP-запроса. Вот зачем мы разделили безопасное и обычное содержимое.

— SSLProtocol отключает все протоколы, отличные от TLS v1.0 и SSL v3.0. Для современных браузеров все будет работать хорошо.

— SSLCipherSuite устанавливает использование только HIGH и MEDIUM шифров. SHA1 считается более безопасным, чем MD5, поэтому выбран он.

— SSLCertificateFile и SSLCertificateKeyFile указывают расположение файлов сертификата и ключа.

— SSLVerifyClient должна быть установлена как ‘none’, если не используется аутентификация примера.

Чтобы запускать обычный сервер на 80 порту, добавьте следующий текст в конфигурационный файл:

NameVirtualHost: *.80
 
    DocumentRoot "/local/www/html"

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

Тестирование.

Создайте базовую страницу index.html в корневой директории вашего сервера, если у вас ещё нет содержимого там.

Затем направьте свой браузер на https://yoursite.com. Вы должны увидеть открытие SSL-соединения и загрузку страницы. Если вы используете сертификат, подписанный вами, ваш браузер даст предупреждение о том, что подлинность сервера не может быть проверена. Вы можете выбрать просмотр сертификата и принять его. Если вы используете внешний сертификат, все должно пройти без проблем.

Убедитесь, что не можете получить доступ к безопасному содержимому, используя http://. Если вы попробуете, вы должны получить сообщение об ошибке.

Устранение проблем.

Если это работает не так, как ожидалось, прежде всего, проверьте, что ваш сервер вообще запущен с помощью команды ps -a | grep apache. Если она не вернет результата, попробуйте перезапустить сервер и проверьте сообщения об ошибке в консоли.

Также проверьте, что права доступа к файлам сертификата и ключа установлены правильно (см. выше), также, как и права к тестовому HTML-файлу и директории, в которой он находится.

Затем, проверьте логи. Вы должны проверить как логи сервера, так и логи SSL, которые вы настроили в конфигурационном файле выше. Если вы не нашли там ничего полезного, попробуйте поменять значение LogLevel в файле конфигурации Apache2 на ‘debug’, перезапустите Apache2 и протестируйте снова. Это должно дать больше данных в логах.

Если вы запускаете веб-сервер на 80 порту, попробуйте запросить страницу с помощью http://, вместо https://, чтобы понять, заключается ли проблема в веб-сервере или в SSL-соединении. Учтите, что в приведенных выше установках, корневые каталоги веб-сервера разные для http:// и https://, так что вы не можете (или не должны!) получить доступ к тому же содержимому. Если ваша тестовая страница в корневом каталоге http:// работает, в то время, как тестовая страница в корневом каталоге https:// не работает, это поможет вам более точно указать на проблему.

Если проблема в SSL соединении, удобным инструментом будет s_client, который является диагностической утилитой для решения проблем в TLS/SSL-соединениях. Обычное его использование: /usr/bin/openssl s_client -connect localhost:443. Также существует множество других опций, которые вы можете узнать из документации. Если вы получили сообщения об ошибках, это должно вам помочь в определении проблемы.

Заключение.

Поздравляю! Теперь у вас есть рабочий безопасный сервер, с сертификатом, автоматически проверяемым большинством современных браузеров.

By sysadmin on 19.02.2009 | FreeBSD, Linux
Метки: , , , ,

Веб-сервер lighttpd

До недавнего времени, Apache не имел серьезных конкурентов с открытым исходным кодом. В последнем обзоре веб-серверов, проведенном Netcraft, мы можем видеть нечто новое. Как и обычно, Apache возглавляет список, Microsoft IIS второй, а знаменитый unknown — третий. Четвертым является Sun Java Web Server (ранее известный как ONE, бывший iPlanet, бывший Netscape). Но пятым номером, обслуживая около 1,4 миллиона сайтов, нечто под названием lighttpd. Откуда это взялось? Мы изучим историю lighttpd, начальную установку и настройку, а также некоторые взгляды на будущее проекта.

Вы можете произносить это название как лайт-ти-пи-ди или, меньше плюясь, лайти. Как бы вы не говорили/выплевывали название этого веб-сервера, вы найдете много информации на его веб-сайте, вики, блоге, или на форумах. lighttpd проектировался как высокоэффективный веб-сервер с низким использованием ресурсов. Он использует гораздо меньше памяти, чем Apache и, как правило, работает быстрее. lighttpd тихо усиливает много высоконагруженных сайтов, включая YouTube, Wikipedia, Meebo и A List Apart; вы увидете, что он часто используется вместо Apache вместе с популярными инструментами, такими как Ruby on Rails и Trac.

Что не так с Apache?

Не смотря на свою популярность, иногда использование Apache не является лучшим решением. Apache предоставляет различные Мульти-Процессные Модели (MPMs) для использования в различных средах работы. Модель prefork — наиболее популярная в Linux — создает определенное число процессов Apache при его запуске и управляет ими в пуле. Альтернативной моделью является worker, которая использует несколько потоков вместо процессов. Хотя потоки легче, чем процессы, вы не можете их использовать до тех пор, пока весь ваш сервер не будет безопасен для потоков (thread safe). Хотя Apache и mod_php — безопасны для потоков, это не гарантирует, что все сторонние модули могут использоваться. Сайт PHP не одобряет использование Apache 2 с потоковой MPM; это замедляет переход разработчиков с Apache 1.3 на 2.x. А модель prefork имеет свои проблемы: каждый процесс (Apache + PHP + сторонние модули) занимает много памяти (30 МБ не является чем-то необычным). Когда вы увеличиваете число одновременных процессов Apache, доступная вам память может быстро кончиться.

lighttpd в тумане.

Некоторые сайты параллельно обрабатывают тысячи файлов, будучи при этом ограничены в памяти и максимальным числом потоков или процессов. Дэн Кегел (Dan Kegel) подробно описал проблемы при обработки тысяч одновременных запросов на своей странице в C10K problem. В 2003 немецкий разработчик MySQL по имени Ян Кнешке (Jan Kneschke) заинтересовался в этой проблеме и решил, что сможет написать веб-сервер, который будет быстрее Apache, сфокусировавшись на правильных методиках. Он спроектировал lighttpd как один процесс с одним потоком и неблокирующимся вводом-выводом. Вместо select, он использовал быстрейшие обработчики событий в целевой системе: poll, epoll, kqueue или /dev/poll. Он выбрал безэкземлярные системные вызовы, как sendfile вместо read и write. В течение нескольких месяцев lighttpd стал обрабатывать статичные файлы быстрее, чем Apache.

Следующим шагом было обработать динамические (CGI) приложения, в частности PHP. Кнешке сдул пыль с FastCGI, разработанном Open Market в самых ранних днях существования интернета, в целях улучшения работы CGI. Вместо того, чтобы веб-сервер запускал ту же внешнюю CGI-программу при каждом вызове, FastCGI по существу был демоном для предварительного запуска CGI-приложения и управления связью между ним и веб-сервером. Это было быстрее, но Perl и PHP позже были внедрены в Apache в качестве модулей, которые были даже быстрее и получали доступ к внутренним действиям Apache по обработке HTTP. FastCGI для Apache стал пренебрегаться, но после того, как он был добавлен в lighttpd и к нему подключили PHP, его производительность равнялась или превышала ту, что показывал Apache с mod_php. В качестве дополнения, в реализацию lighttpd была добавлена автоматическая балансировка загрузки.

lighttpd был также расширен модулями для управления виртуальными хостами, переадресации, перезаписи URL, аутентификации и других полезных вещей. В большинстве случаев, все, что вы можете сделать в Apache, вы можете сделать в lighttpd. В следующих разделах я покажу, как установить и настроить lighttpd с оглядкой на Apache.

Установка lighttpd.

Давайте установим lighttpd и поковыряемся в нем образными палочками. Страница установки на вики дает примеры установки бинарников или из исходников для различных дистрибутивов Linux. Для разработчиков с волосатой грудью (эти волосы не обязательно должны быть вашими), полная установка из исходников выглядит так:

    # wget http://www.lighttpd.net/download/lighttpd-1.4.13.tar.gz
    # tar xvzf lighttpd-1.4.13.tar.gz
    # cd lighttpd-1.4.13
        # ./configure
    # make
    # make install

Это установит lighttpd в /usr/local. Если сборка не удалась, проверьте, что требуемые пакеты разработки pcre и zlib установлены в вашей системе.

Если вы хотите запускать и останавливать lighttpd вручную, то вперед. А чтобы установить lighttpd как сервис вроде Apache, отредактируйте и установите скрипт инициализации:

    # sed -e 's/FOO/lighttpd/g' doc/rc.lighttpd &gt; lighttpd.init
    # chmod a+rx lighttpd.init
    # cp lighttpd.init /etc/init.d/lighttpd
    # cp -p doc/sysconfig.lighttpd /etc/sysconfig/lighttpd
    # install -Dp ./doc/lighttpd.conf /etc/lighttpd/lighttpd.conf
        # chkconfig lighttpd on

Начальная настройка.

С виду синтаксис файлов настройки lighttpd может иметь отличия от Apache. Примеры со страницы настройки из вики выглядят больше похожими на Perl (или PHP, или Python), нежели чем на стиль XML httpd.conf в Apache. Для простого сайта со статическими файлами, вам нужно указать те же вещи, что и в Apache: document root, расположение access и error логов и имена user и group для работы сервера. Вот эквивалентные варианты Apache (httpd.conf) и lighttpd (lighttpd.conf):

Apache:

DocumentRoot /var/www/html
 
CustomLog /var/www/logs/access
 
ErrorLog /var/www/logs/error
 
User www
 
Group www

lighttpd:

server.document-root = "/var/www/html"
 
accesslog.filename = "/var/www/logs/access"
 
server.errorlog = "/var/www/logs/error"
 
server.username = "www"
 
server.groupname = "www"
 
server.modules = ( "mod_accesslog" )

Механизм включения модулей в lighttpd похож на тот, что в Apache, так что файл lighttpd.conf не должен расти. Чтобы использовать дополнительный модуль, вам нужно включить его и установить его опции. В Apache это делается с помощью LoadModule, а lighttpd просто включает незакомментированный модуль в массиве server.modules. Пока что вам нужен только mod_accesslog.

Аутентификация и авторизация.

lighttpd не поддерживает файлы .htaccess, так что вам нужно указывать все настройки в файле lighttpd.conf, или в файлах, к нему подключенным. Он понимает файлы пользователей Apache для простой и общей аутентификации, но поддержка групповых файлов ещё не реализована. Вот пример, как защитить паролем высокоуровневый каталог под названием special:

Apache:

  AuthName "My Special Directory"
 
  AuthType Basic
 
  AuthUserFile /var/www/passwords/users
 
  Order deny,allow
 
  require valid-user

lighttpd:

auth.backend = "htpasswd"
 
auth.backend.htpasswd.userfile = "/var/www/passwords/users"
 
auth.require = ( "/special/" =&gt;
 
  (
 
  "method"   =&gt; "basic",
 
  "realm"    =&gt; "My Special Directory",
 
  "require"  =&gt; "valid-user"
 
  )
 
)

Виртуальные хосты.

Вот другая задача для вашего нагруженного и недооцененного веб-сервера: управлять двумя сайтами с названиями scratch.example.com и sniff.example.com:

Apache:

NameVirtualHost *
 
  ServerName "scratch.example.com"
 
  DocumentRoot "/var/www/hosts/scratch/docs"
 
  ServerName "sniff.example.com"
 
  DocumentRoot "/var/www/hosts/sniff/docs"

lighttpd:

$HTTP["host"] == "scratch.example.com" {
 
  server.document-root = "/var/www/hosts/scratch/docs/" }
 
$HTTP["host"] == "sniff.example.com" {
 
  server.document-root = "/var/www/hosts/sniff/docs/" }

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

Apache:

LoadModule vhost_alias_module modules/mod_vhost_alias.so
 
VirtualDocumentRoot /var/www/hosts/%1/docs

lighttpd:

server.modules = ( ..., "mod_evhost", ... )
 
evhost.path-pattern = "/var/www/hosts/%3/docs"

Server-Side Includes (SSI)

Первым шагом к динамическому контенту будет простое включение SSI для файлов с расширением .shtml:

Apache:

AddHandler server-parsed .shtml

lighttpd:

server.modules = ( ..., "mod_ssi", ... )
 
ssi.extension = ( "shtml" )

PHP

lighttpd оптимизирует производительность обработки статичного файла с помощью выгрузки динамического контента, загружающего ЦПУ в другой процесс. Вместо обработки PHP внутри, как делает Apache с mod_php, lighttpd передает эту задачу FastCGI. Следующие примеры конфигурации превращают скучные, безжизненные .php-файлы в живые PHP скрипты. Чтобы ознакомиться с более пикантными деталями, чем те, что мы можем показать на этом сайте, посмотрите эту страницу.

Apache:

LoadModule php5_module modules/libphp5.so
 
AddType application/x-httpd-php .php

lighttpd:

server.modules = ( ..., "mod_fastcgi", ... )
 
fastcgi.server =
 
  ( ".php" =&gt;
 
    ( "localhost" =&gt;
 
      (
 
      "socket" =&gt; "/tmp/php-fastcgi.socket",
 
      "bin-path" =&gt; "/usr/local/bin/php"
 
      )
 
    )
 
  )

Достоинства lighttpd

lighttpd включает в себя модули, эквивалентные модулям Apache для сжатия, просмотра каталогов, пользовательских каталогов, SSL, WebDAV, перезаписи URL и переадресации. Вы можете прочитать об этом на сайте. Другие интересные модули lighttpd являются уникальными.

Если вы хотите сделать мини-YouTube, мы можете параллельно показывать тысячи флеш-роликов с помощью модуля mod_flv_streaming. YouTube обрабатывает его собственные статические файлы с помощью lighttpd, хотя ещё не использует этот модуль.

Если у вас есть такой сайт с большим количеством флеш-файлов, как вам защититься от хотлинкинга? Решением этой проблемы в lighttpd, подходящим для любых типов файлов, является mod_secdownload. Вы пишете функцию (примеры по ссылке написаны на PHP и Ruby) для генерирования специального URL, а модуль обрабатывает этот URL для предоставления доступа к определенному файлу на определенный период времени.

Лайти Один Пять Ноль.

В данный момент Кнешке разрабатывает версию 1.5.0, которая увеличит производительность и гибкость. Новая подсистема ввода-вывода улучшает производительность с помощью тредов (в данном случае треды имеют смысл) и асинхронный ввод-вывод, будь то POSIX, собственный в Linux или пользовательская оболочка gthread в glib 2.0.

Модуль mod_proxy_core объединяет три бэкенд модуля: mod-proxy, mod-fastcgi и mod-scgi. Отделение протоколов от основной обработки дает балансировку нагрузки (четырех видов!), преодоление отказа, удержание соединения и внутреннее формирование очереди к основной функции прокси.

Ожидается, что новый модуль под названием mod_magnet сыграет большую роль в будущем lighttpd. Он дает доступ к разным фазам HTTP запроса и ответа, включая задачи вроде перезаписи URL и генерации контента. Интересным выбором было использование в нем встроенного скриптового языка Lua вместо сложной грамматики, как в mod_rewrite Apache. Посмотрим, понравится ли это разработчикам, или они будут придерживаться знакомым, хотя иногда и сложным, правилам Apache.

Куда Лайти?

Кнешке видит будущее lighttpd в двух направлениях:

— Высокопроизводительные, широкодоступные поставщики контента

— Встроенные сервера, кросс-компиляция, использовать мало памяти

После 1.5.0, mod_magnet будет предоставлять больше динамической конфигурации сервера. Это может привлечь некоторых пользователей Apache, отказавшихся от перехода на lighttpd из-за отсутствия поддержки .htaccess. Я с нетерпением жду запланированную поддержку Comet — обратная сторона AJAX, в которой сервер обновляет клиента при поступлении новых данных. Это имеет приложения к панелям управления веб-приложений, чатам и другим высокоинтерактивным приложениям. С помощью AJAX и Comet, веб-приложения могут выглядеть гораздо более похожими на приложения с традиционным GUI. Но даже без этих новых возможностей, lighttpd уже является сильным конкурентом для Apache, особенно при ограничениях в памяти или обработке множества статических файлов. Легкость — это хорошо.

By sysadmin on 18.02.2009 | FreeBSD, Linux
Метки: , , , ,