Женщины как вeб-сервер: 400 Bad Request - свидание без букета 401 Unauthorized - замужем 402 Payment Required - ужин при свечах 403 Forbidden - руки прочь! 404 Not Found - сегодня я гуляю с подругами 405 Method Not Allowed - Не-е, не с зади... 406 Method Not Acceptable - ...только не сосать! 407 Proxy Auth. Required - надо спросить маму 408 Request Timeout - знаешь колько ты уже не звонил? 409 Conflict - что это там была, за блондинка вчера? 410 Document Removed - хочу развода 411 Lenght Required - что? это ты называешь длинным? 412 Precondition Failed - что? у тебя нет презерватива? 413 Request Entity Too Large - Такой не влезит! 415 Unsupported Media Type - нее, вчетвером не интерестно. 500 Internal Server Error - месячные 501 Not Implemented - ещё никогда не пробовала 502 Bad Gateway - ...фу, солёно! 503 Service Unavailable - голова болит 504 Gateway Timeout - это уже всё?
В последнее время возможность управления приложением при помощи WEB интерфейса становится все более популярной. Лично я применил возможность удаленного управления в ряде своих программ, и это существенно упростило их сопровождение в условиях большой организации. Delphi содержит достаточно мощные компоненты, позволяющие легко организовывать соединения по протоколу TCP/IP. Это компоненты TServerSocket и TClientSocket. Для организации WEB сервера нам потребуется только TServerSocket. Для доступа к нашему серверу применим порт с номером 5000 (напоминаю, что порты с номерами меньше 1024 могут использоваться только по назначению и есть опасность, что на Вашей машине будет установлено некоторое приложение, использующее стандартный порт HTTP 80). При этом URL будет выглядеть как machine:5000/path при доступе из сети или 127.0.0.1:5000/path при доступе с локального хоста. Следует сразу поговорить о двух тонкостях, не имеющих прямого отношения к написанию WEB сервера - Два приложения на одном компьютере не могут одновременно использовать один и тот-же порт. Поэтому следует выносить номер порта в настройки программы и (или) предусматривать механизм автоматического выбора одного из альтернативных портов на случай, если основной уже занят.
- Следствием из несоблюдения пункта 1 является невозможность запуска двух копий одной программы без принятия соответствующих мер
- Программа может быть запущена на компьютере, не настроенном на работу с сетью. Попытка использования компонента TServerSocket в этом случае приведет к ошибкам, которые могут помешать нормальному запуску программы.
Решением всех этих проблем может послужить следующий совет: никогда не ставьте свойство Active:= true; во время дизайна !! Активируйте компонент TServerSocket при старте программы в конструкции try ... except; Итак, мы поговорили об общих вопросах. Теперь следует поговорить о протоколе HTTP. Протокол HTTP - краткая справочная информация. Обмен по протоколу HTTP производится в т.н. транзакциях, которые состоят из трех шагов - Установка соединения. Производится по инициативе клиента и для этого необходимо знать порт, по которому работает сервер.
- Запрос клиента. Клиент передает серверу HTTP запрос (содержащий HTTP метод, идентификатор ресурса и версию протокола) + дополнительную информацию. Пример типового запроса "GET /book/index.htm HTTP/1.0". Запрос как правило завершается пустой строкой и обязательным CRLF. Вот полный пример запроса IE5 (перехваченный кстати при помощи примера 2):
GET /btn7.gif HTTP/1.1 Accept: */* Referer: http://127.0.0.1:5000/ Accept-Language: ru Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: 127.0.0.1:5000 Connection: Keep-Alive
|
- Ответ сервера. Сервер в ответ выдает HTTP ответ + дополнительные данные + запрошенную инфомацию (если требуется). Ответ сервера всегда состоит из строки с версией протокола HTTP, пробела, трехзначного кода статуса, за которым через пробел может следовать его расшифровка. После этого передается CRLF (символов с кодами 0Dh, 0Ah), затем идет необязательная информационная часть в формате параметр=значение и наконец завершается ответ еще одной парой символов CRLF. Затем следует запрошенная информация (если ее передача возможна и требуется в данном контексте). Пример ответа - "НТТР/1.0 200 OK". 4. Сервер разрывает соединение с клиентом, что служит сигналом к завершению обмена Клиент тоже может прервать обмен на любой стадии, разорвав соединение с сервером. Особенно это любит делать IE. Он выдает запрос, получает ответ и начинает получать данные, а тем временем анализируя полученный ответ выясняет, что запрошенный ресурс уже есть в кеше и его не требуется загружать. При этом IE разрывает соединение и прерывает загрузку. Аналогично он ведет себя при нажатии кнопки "Стоп". Поэтому при начальном тестировании я бы рекомендовал использовать программу Net Vampire, которая отображает подробный протокол обмена с сервером (что и когда передано на сервер и что принято в ответ).
Классы кодов ответа HTTP. Как говорилось ранее, код ответа представляет собой трехзначное число. Коды сгруппированы в пять категорий, категория определяется первой цифрой - 1** Информационная. На данный момент зарезервирована
- 2** Успешно. Сообщает об успешном выполнении запроса
- 3** Перенаправление. Указывает клиенту, что для выполнения запроса необходимы дополнительные действия
- 4** Ошибка клиента. Сообщает клиенту о том, что запрос неполный или содержит синтаксические ошибки. Кроме того, ошибки этой категории возникают, если запрошенный ресурс не найден или недоступен
- 5** Ошибка сервера. Возникает, если сервер перегружен, недоступен или в работе сервера возникли какие либо ошибки
Наибольший интерес представляют собой следующие коды (они наиболее распространены). коды WEB-сервера - 200 ОК
- 201 Успешная команда POST
- 202 Запрос принят
- 203 Запрос GET либо HEAD выполнен
- 204 Запрос выполнен, но нет содержимого
- 300 Ресурс обнаружен в нескольких местах
- 301 Ресурс удален навсегда
- 302 Ресурс временно удален
- 304 Ресурс изменен
- 400 Плохой запрос от клиента
- 401 Неавторизованный запрос
- 402 Необходима оплата за запрос
- 403 Доступ к ресурсу запрещен
- 404 Ресурс не найден
- 405 Метод неприменим для данного ресурса
- 406 Недопустимый тип ресурса
- 410 Ресурс недоступен
- 500 Внутренняя ошибка сервера
- 501 Метод не выполнен
- 502 Перегрузка сервера или неисправный шлюз
- 503 Сервер недоступен или таймаут шлюза
Методы протокола HTTP Данная статья не преследует цель описать подробность протокола HTTP, но для понимания принципов работы примера рассмотрим несколько основных методов: Метод GET Метод GET является самым часто используемым и предназначен для получения информации от сервера. В качестве информации может выступать файл или результаты работы какого либо процесса, например CGI. Метод GET может дополняться условием при помощи параметра If-Modified-Since в запросе - в том случае результат передается только если ресурс имеет дату модификации, большую указанной в If-Modified-Since. Кроме запроса метод GET может применяться для передаче небольших объемов данных в виде параметров. Метод HEAD Метод HEAD полностью аналогичен методу GET, но в ответ сервер передает только заголовок (но не передает данные). Метод POST Метод POST применяется для передачи серверу данных Метод PUT Метод PUT предназначен для сохранения данных, переданных после заголовка запроса, под именем, указанным в запросе. Метод DELETE Метод DELETE используется для удаления ресурсов с указанным в запросе именем Итак, мы поговорили о теории (причем это не теория, а краткий ликбез). Найти более подробное описание достаточно легко, есть масса сайтов, специализирующихся на подобной документации. Однако лучше всего почитать стандарты RFC (в частности, документ RFC2068) Я не хочу приводить здесь сами исходные тексты - страничка получится очень большой, поэтому остальная часть стальи в виде двух хорошо продокументированных проекта лежит в архивах: Пример 1. Простейший Web сервер - база для управления программой через WEB. В примере номер 1 мы рассмотрим создание простейший WEB сервер. В ответ на любой запрос он выдает одну и туже страничку с информацией о клиенте и формой, демонстрирующей передачу запросов серверу по методу GET. Данный пример может служить прототипом для систем удаленного управления/администрирования с WEB интерфейсом. Пример 2. Обычный Web сервер - база для разработки своих серверов. В этом примере рассмотрен полнофункциональный сервер. У него определяется директорий, в котором будут храниться файлы и он может возвращать их по запросам клиентской программы. Я ради эксперимента разместил на нем свой сайт по Delphi (с которого Вы сейчас читаете эту статью), и он прекрасно открылся при помощи IE. Единственный огрех - периодически вылетала ошибка socket error 10054, связанная с тем, что IE брал странички из кеша и рвал соединение в процессе их передачи.
|