remix (1119427), страница 3
Текст из файла (страница 3)
Поэтому браузер имеет возможность сохранить ресурс локально при первом обращении к нему и при последующих обращениях использовать эту копию без настоящей закачки в случае, если ресурс не изменился. А выяснить неизменность ресурса и помогает метод HEAD.3.3. HTTP-ответОтвет веб-сервера имеет следующую структуру:<заголовок ответа> <конец строки><HTTP-заголовок> <конец строки>...<HTTP-заголовок> <конец строки><конец строки><тело ответа>Заголовок ответа выглядит так:HTTP/‹версия протокола› ‹код состояния› ‹пояснение›‹версия протокола› — то же самое, что и в HTTP-запросе. Модельныйсервер для простоты поддерживает версию 1.0.‹код состояния› — десятичное число (три арабских цифры), характеризующее дальнейшее сообщение и определяющее реакцию клиента.‹пояснение› — короткая необязательная строка, содержащая пояснениек коду состояния.
Нужна только для облегчения анализа ответа человеком.11Основные понятияВеб-сервер генерирует ответ на любой запрос веб-клиента.В случае, если метод в запросе не поддерживается сервером, то последний должен вернуть код состояния 501 (пояснение — Not implemented).При этом в ответ должен включаться HTTP-заголовок Allow, содержащийсписок допустимых методов (описание заголовков, поддерживаемых модельным сервером см. ниже).Если же метод поддерживается сервером (т.е.
это GET или HEAD длямодельного сервера), и файл, идентифицируемый URI, допустим и доступен,то сервер выдает ответ с кодом состояния 200 (Ok). Текст файла-ресурсавключается в ответ как тело ответа, при этом в ответ должны включатьсязаголовки Content-type, определяющий тип содержимого ресурса (см. ниже),и Content-length, содержащий длину тела в байтах. Вообще говоря эти заголовки должны включаться в ответ всегда, когда он содержит тело (а не толькозаголовки).И, наконец, возможен случай (весьма частый!), когда указанный в запросе ресурс не найден.
В этом случае выдается ответ с кодом статуса 404(Not found). При этом сервер должен вернуть более развернутое, чем Notfound, гипертекстовое пояснение в теле ответа (правда, в случае методаHEAD этого делать не надо).Ниже приводится информация о всех кодах состояния, возвращаемыхмодельным веб-сервером, и соответствующий список заголовков (о самихзаголовках — см. ниже).3.3.3 Коды состояния, возвращаемыемодельным серверомКоды состояния разбиваются на пять групп (номер группы — первая цифракода).— 100–199 — Информация. Модельный сервер их не поддерживает.— 200–299 — Успех.
Сервер возвращает такие ответы в случае успешной и безошибочной обработки запроса.— 300–399 — Перенаправление. Модельный сервер их не поддерживает.— 400–499 — Ошибка клиента. Ответы информируют об ошибках взапросе. Для всех методов кроме HEAD сервер должен вернуть в телеответа развернутое гипертекстовое сообщение об ошибке, котороеклиент-браузер должен показать пользователю.— 500–599 — Ошибка сервера. Ответы информируют об ошибках повине сервера.
Также, как и в случае четвертой группы, в теле ответасодержится гипертекстовое сообщение об ошибке.В нижеследующей таблице перечислен минимальный набор кодов состояния, возвращаемых модельным веб-сервером.12Основные понятияТаблица 1. Некоторые коды состояния модельного веб-сервераКод состоянияи пояснениеСмыслHTTP-заголовки200 OKЗапрос ресурса успешенDate, Server,Content-type-дляGET, Contentlength — для GET,Last-modified,тело — для GET400 Bad requestСинтаксическая ошибка взапросеDate, Server, Content-type,Content-length,тело403 ForbiddenЗапрос ресурса, которыйнедоступен клиентуDate, Server,Content-type,Content-length,тело404 Not FoundЗапрос несуществующегоресурсаDate, Server,Content-type,Content-length,тело500 Internal Server ErrorЛюбая ошибка сервера,которая не входитв список ошибок 5 классаDate, Server,Content-type,Content-length,тело501 Not ImplementedСервер не имеет возможности обработать запрос(например, не поддерживает метод)Date, Server, Allow,Content-type,Content-length,тело503 Service UnavailableСервер временно не имеетвозможности обработатьзапрос (например, из-занехватки системных ресурсов, перегрузки и т.п.)Date, Server,Content-type,Content-length,тело3.4.
HTTP-заголовокКаждый HTTP-заголовок представляет собой строку вида:‹имя заголовка› : ‹значение›Двоеточие должно следовать сразу за именем заголовка. Значение может содержать произвольные символы, кроме «\n» (перевод строки) и «\r»(возврат каретки).Заголовки делятся на 4 группы:— Основные заголовки — должны входить в любой запрос и ответ;— Заголовки запроса — входят только в запрос от клиента;13Основные понятия— Заголовки ответа — входят только в ответ сервера;— Заголовки сущности — сопровождают каждую сущность запросаили ответаМодельный сервер поддерживает следующие заголовки:— Основные — Date— Запрос— Host, Referer, User-agent— Ответ— Server— Сущности — Content-length, Content-type, Allow, Last-modified3.4.3 Заголовок DateЗаголовок Date содержит дату генерации сообщения.
Формат даты, поддерживаемый модельным веб-сервером:Www, dd Mmm YYYY hh:mm:ss GMTОбратите внимание, что время указывается по Гринвичу (GMT). Здесь:— Www — первые три буквы дня недели (по-английски), например,Wed;— dd — день (две цифры);— Mmm — первые три буквы названия месяца (по-английски), например, Apr;— YYYY — год (четыре цифры);— hh:mm:ss — часы, минуты, секунды, соответственно (две цифры).Пример:Date: Wed, 01 Apr 2009 21:00:05 GMT3.4.4 Заголовок HostЗаголовок Host содержит доменное имя хоста и порт сервера для запрашиваемого ресурса.Пример:Host: al.cs.msu.ru:80803.4.5 Заголовок RefererСодержит URI ресурса, с которого клиент сделал текущий запрос.14Основные понятияПример:Referer: http://127.0.0.1/testpage.html3.4.6 Заголовок User-agentСодержит название программы-клиента и его характеристики.Пример:User-Agent: SomeStrangeBrowser/0.23.4.7 Заголовок ServerСодержит название веб-сервера и его характеристики.Пример:Server: Model HTTP Server/0.13.4.8 Заголовок Content-lengthСодержит (в десятичном виде) число байтов в теле сообщения.Пример:Content-Length: 953.4.9 Заголовок Content-typeСодержит т.н.
MIME-формат возвращаемого ресурса. MIME-формат записывается в виде: ‹тип›/‹подтип›.Модельный сервер поддерживает следующие форматы: text/plain,text/html,image/jpeg.Пример:Content-Type: text/html3.4.10 Заголовок AllowСодержит список методов, поддерживаемых сервером.15Основные понятияПример:Allow: GET, HEAD3.4.11 Заголовок Last-modifiedСодержит дату последней модификации запрошенного ресурса. Форматаналогичен формату даты в заголовке Date.Пример:Date: Wed, 01 Apr 2009 21:32:12 GMT16Методические указания по выполнению первого этапа задания4. Методические указанияпо выполнению первогоэтапа заданияЦелью первого этапа задания является реализация статического веб-сервера,поддерживающего подмножество HTTP-протокола, описанное выше.Рекомендуется начать реализацию с двух простых программ, которыепригодятся при тестировании.Первая программа — «псевдо-сервер», цель которого — запись реальных запросов, посылаемых веб-клиентами (например, различнымивеб-браузерами).
Такой сервер должен принять запрос, записать его влог-файл, выдать ответ с кодом 501 «Not Implemented» и немедленно закрытьсоединение. Ответ можно заготовить заранее как текстовый файл и выдаватьего в сокет по мере надобности. Сохраненные запросы можно использоватьдля отладки сервера.Для того, чтобы посылать эти запросы к серверу, понадобится еще однопростое приложение — «псевдо-браузер». Это консольное приложение, которое устанавливает связь с сервером, посылает ему заранее заготовленныйзапрос (тут-то пригодится «псевдо-сервер», хотя тестовые запросы можноприготовить и «вручную») и записывает ответ сервера.4.1.
Внутренняя организациясервераРассмотрим вначале самую простую схему организации сервера, назовем ее«монопольной». В этой схеме сервер принимает запрос от клиента, обрабатывает его, формирует ответ, отсылает его клиенту и закрывает соединение.Схема монопольна, потому что сервер не может принимать других запросов,пока не обработает текущий запрос.Псевдокод для такой схемы может выглядеть так:// обычная подготовка TCP/IP сервераint serverSocket = socket ( AF_INET, SOCK_STREAM, 0 );// ...struct sockaddr_in ServerAddress;// заполнить ServerAddress17Методические указания по выполнению первого этапа задания// ...if ( bind ( serverSocket, &ServerAddress,sizeof ( ServerAddress ) ) < 0 ){// фатальная ошибка// ...}if ( listen ( serverSocket, BACK_LOG ) < 0 ){// фатальная ошибка// ...}// главный циклfor (;;){struct sockaddr_in ClientAddress;size_t ClAddrLen = sizeof ( ClientAddress );// ждем очередного клиентаint clSocket = accept ( ( serverSocket, &ClientAddress,&ClAddrLen );if ( clSocket < 0 ){// ошибка — если будет повторяться, то фатальна// ...}/* собственно обработка запроса.
Должна включатьв себя корректный разрыв связи (shutdown — close) */ProcessClientRequest ( clSocket, &ClientAddress );}// ...Приведенная схема имеет одно (и, пожалуй, единственное) достоинство — простоту. Например, псевдо-сервер (см. выше) целесообразно реализовать именно так. Однако никакой реальный сервер не использует эту схемупо причине её крайней неэффективности. Проблема в том, что обработкакорректного клиентского GET-запроса требует копирования файла (указанного в URI запроса) в клиентский сокет.
Эта операция может занять многовремени. Особенно нетерпимо то, что сервер в течение этого времени будетпростаивать, ожидая завершения обмена с файлом и сокетом. Ведь в это жевремя можно обрабатывать запросы других клиентов! Поэтому более эффективная (и более сложная в реализации) схема использует асинхронныйввод/вывод.
Главную роль в этой схеме играет системный вызов select().Прочитать о том, как select() используется для асинхронного ввода/выводаможно в [4, гл.6]. Здесь отметим, что для достижения максимальной эффективности асинхронным должен быть не только обмен с сокетами, но и обменс файлами-ресурсами. Для этого дескриптор открытого файла ресурса должен быть переведен в режим неблокирующего ввода с помощью системноговызова ioctl(). Заметим, что особенность реализации механизма сокетов в ОСUNIX такова, что открытые файловые дескрипторы не отличаются от открытых сокетов с точки зрения системного вызова select(), поэтому select()реагирует не только на «сокетные» события, но и на «файловые» события, чтосущественно упрощает реализацию асинхронного ввода/вывода.18Методические указания по выполнению первого этапа задания4.2.
Общий интерфейс шлюза —основные понятияОбщий интерфейс шлюза (или общий шлюзовой интерфейс —по-английски — Common Gateway Interface, CGI) — это стандартизованныйпротокол, позволяющий подключить к веб-серверу внешние программы длягенерации содержимого запрашиваемых ресурсов. Такие программы называются «шлюзами», но мы будем использовать более распространенныйтермин «CGI-программа».
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
