Якович (1207873), страница 3

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

Текст из файла (страница 3)

«*» указывает на то, что запрос направлен напрямую к серверу, и допускается только в том случае, когда метод не обязательно обращается к ресурсу. Например, OPTIONS * HTTP/1.1.

«Абсолютный_URI» используется и необходим, если запрос производится через прокси-сервер. Прокси-сервер перенаправляет запрос на сервер или обслуживает его, пользуясь кэшем, и возвращает ответ. Прокси-сервер в состоянии переслать запрос другому прокси-серверу или непосредственно серверу, определенному абсолютным_URI. Во избежание зацикливания запроса, прокси-серверу нужно уметь распознавать все имена сервера, любые псевдонимы, локальные разновидности, и числовые IP адреса. Request-Line в случае прокси-сервера может иметь следующую структуру:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Поля заголовка запроса дают возможность передать серверу дополнительную информацию о клиенте и о запросе. Их перечень: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, From, Host, If-Modified-Since, If-Match, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, User-Agent. Неизвестные поля обрабатываются как поля заголовка объекта (entity-header).

1.7 HTTP ответ (Response)

Получив и интерпретировав сообщение запроса, сервер собирает ответное сообщение, имеющее следующий вид:

Ответ = Status-Line *( general-header | response-header | entity-header ) CRLF [ message-body ].

В ответе первую строку занимает строка состояния. Она содержит в себе версию HTTP, код состояния (Status-Code) и поясняющую фразу (Reason-Phrase), которые разделены «пробелами». В конце строки состояния находится переход на новую строку CRLF.

Status-Line = Версия HTTP Код-состояния Поясняющая-фраза CRLF

Код состояния – это трехразрядный целочисленный код, соответствующий результату обработки запроса. Он предназначен для использования автоматами. Всего зарезервировано более двух десятков кодов.

Поясняющая фраза – это короткое описания кода состояния. Предназначена для пояснения кода состояния пользователям.

Старший разряд кода состояния характеризует класс ответа. Остальные разряды классифицируют состояние и описывают его. Существуют следующие классы ответов:

– 1xx: Информационные – обработка полученного запроса;

– 2xx: Коды успеха – запрос принят, успешно обработан;

– 3xx: Перенаправление – указывают, что для выполнения запроса требуются определенные действия;

– 4xx: Коды ошибок со стороны клиента – указывают на то, что запрос клиента некорректен;

– 5xx: Коды ошибок на стороне сервера – указывают на то, что сервер не в состоянии обработать запрос.

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

Поля заголовка ответа дают возможность серверу сообщать дополнительную информацию о себе или ответе, которую нельзя разместить в строке состояния. Перечень заголовков ответа: Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning, WWW-Authenticate. Неизвестные поля обрабатываются как поля заголовка объекта (entity-header).

1.8 HTTP методы

OPTIONS

OPTIONS – запрос информации о параметрах соединения, доступных в рамках текущей цепи запросов и ответов. Этот метод позволяет клиенту определять параметры и(или) требования для запрашиваемого ресурса, или возможности сервера, обрабатывающего запрос, при этом не осуществляя никаких действий над ресурсом и не запуская его загрузку.

Если сервер не отдал сообщение об ошибке, то в ответе не должно находиться никакой информации, кроме информации, которая содержит в себе описание параметров.

– Если Request-URI равен «*», то OPTIONS предназначен для обращения к серверу. В случае успеха, серверу следует перечислить поля, указывающие на опциональные возможности сервера, а также любые расширения, не определенные спецификацией протокола, в дополнение к общим полям или полям заголовка ответа. OPTIONS * может быть использован через прокси-сервер с определением адресуемого сервера в Request-URI.

– Если Request-URI не равен «*», то OPTIONS применяется к параметрам, которые доступны при запросе на указанный ресурс. В случае успеха, серверу следует перечислить поля, указывающие на опциональные возможности сервера, а также любые расширения, не определенные спецификацией протокола, в дополнение к общим полям или полям заголовка ответа.

– Если OPTIONS проходит через прокси-сервер, то последний редактирует ответ и исключает параметры, которые не предусмотрены возможностями данного прокси-сервера.

GET

Метод GET даёт возможность получить любую информацию (в качестве объекта), идентифицированную Request-URI. Если Request-URI обращается к программе, которая подготавливает данные, то в качестве объекта в ответе должны быть подготовленные ей данные, но не исходный код программы.

Существует два вида GET. Первый, «условный», когда сообщение запроса содержит поля If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Такой GET запрашивает объект, только если объект удовлетворяет условиям, описанным в полях заголовка. Он предназначен для устранения излишней загрузки на сеть, и даёт возможность обновлять объекты в кэше не используя несколько запросов или пересылку данных, уже сохраненных у клиента.

Второй вид – «частичный», когда сообщение запроса включает поле Range. Такой GET запрашивает только часть объекта, а не целиком. Он предназначен для устранения излишней загрузки на сеть, и даёт возможность обновлять объекты в кэше не используя несколько запросов или пересылку данных, уже сохраненных у клиента.

HEAD

Отличается от GET только тем, что не требует от сервера передать в ответе тело сообщения. HEAD можно использовать для получения метаинформации об объекте запроса без передачи тела объекта (entity-body). В основном, этот метод используется в целях проверки целостности, верности, достижимости, и времени модификации запросов.

POST

Применим для запроса, когда сервер принимает объект, содержащийся в запросе. POST может быть использован для следующих целей:

– Описание существующих ресурсов;

– Регистрация сообщения на электронной доске объявлений, в группе новостей, списке рассылки, или подобной группе статей;

– Передача блока данных: результат ввода в форме, процессу обработки;

– Расширение базы данных посредством конкатенирующей операции.

Как правило, функция, выполняемая методом POST, определена сервером для конкретного ресурса и зависит от Request-URI. Передаваемый с помощью POST объект, относится к URI как файл к каталогу, в котором находится, статья относится к группе новостей, а запись относится к базе данных.

В случае успешного создания ресурса, сервер должен в ответе передать код состояния 201 (Создан) и содержать объект, который описывает состояние запроса и ссылается на новый ресурс, и заголовок Location.

PUT

Данный запрос схож с POST, но в результате не создаётся новый ресурс, а модифицируется старый. Если Request-URI направлена к существующему ресурсу, содержащийся в запросе объект рассматривается как модифицированная версия этого ресурса, который расположен на сервере.

В таком случае серверу следует передать ответ содержащий код состояния 200 (успешно) или 204 (нет содержимого). Если ресурс не существует, то создается новый ресурс на данном URI. В этом случае, серверу следует передать ответ с кодом состояния 201 (создан). В случае, когда ресурс нельзя создать, серверу следует передать в ответе тело сообщение, которое опишет суть проблемы. Когда сервер не может обработать PUT запрос, ему следует указать код состояния 501 (не реализовано).

Основная разница между PUT и POST в разной интерпретации запрашиваемого URI. POST идентифицирует ресурс, обрабатывающий содержащийся объект. Это может быть процесс, который принимает данные, шлюз к протоколу, или отдельный объект. В случае PUT, URI интерпретируется как объект, включенный в запрос. В случае недоступности объекта по URI, но доступности его на другом URI, серверу следует ответить кодом состояния 301(перемещен навсегда) и предоставить клиенту выбор, перейти на новый ресурс или отказаться от запроса.

Некоторый ресурс может идентифицироваться некоторым числом различных URI. К примеру, статья подвергается редакции и имеет несколько версий, при этом URI идентифицирующий текущую «версию», может отличаться от URI, который идентифицирует иную версию.

DELETE

Запрос с целью удаления ресурса на сервере, идентифицируемого с помощью URI. Запрос не гарантирует удаление ресурса, это зависит от сервера. Сервер может предоставлять выбор, отказаться или удалить. В любом случае, серверу следует передать в ответе корректный код состояния и тело сообщения, поясняющее ответ.

1.9 Коды состояния, описание

1xx. Информационные коды:

Характеризуют предварительный ответ сервера, состоят только из строки состояния и опциональных заголовков.

100: Продолжать (Continue)

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

101: Переключение протоколов (Switching Protocols)

Сообщает серверу с помощью поля заголовка сообщения Upgrade, что нужно воспользоваться другим протоколом. После чего сервер выполняет переключение между протоколами. Это используется только при условии, что в этом есть выгода. Например, переключение с HTTP 1.0 на HTTP 1.1.

2xx. Коды успеха:

Характеризуют успешную обработку запроса клиента сервером.

200: Успешно (OK)

Запрос выполнен без ошибок. Информация в ответе на данный запрос будет зависеть от используемого метода:

– GET: в ответе передается объект, который соответствует запрашиваемому ресурсу;

– HEAD: в ответе передаются поля заголовка объекта, соответствующие запрашиваемому ресурсу. Тело сообщения не передается;

– POST: в ответе передается информация об объекте или результат запроса.

201: Создан (Created)

Запрос выполнен успешно и новый ресурс был успешно создан, у созданного ресурса теперь есть URI по которому к нему можно обратиться. В теле сообщения ответа серверу следует указывать URI для созданного ресурса. Если создать ресурс в данное время невозможно, серверу следует возвратить ответ с кодом состояния 202 (принято) вместо 201.

202: Принято (Accepted)

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

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

204: Нет содержимого (No Content)

Запрос выполнен успешно, но нет свежей информации, которую сервер мог бы вернуть клиенту. Данный ответ не содержит тело сообщения, но может добавить новые заголовки к ответу на запрос.

205: Сбросить содержимое (Reset Content)

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

206: Часть содержимого (Partial Content).

Выполнена часть запроса GET для определенного ресурса. В таком случае, запрос должен иметь поле Range в заголовках, которое сообщает в каком диапазоне выбрать данные. Для такого запроса ответ должен возвращать также поле заголовка Content-Range, указывающее выбранную часть данных и поле Content-Type должно быть равно «Multipart/Byteranges». Если не указывать описанные выше поля в ответе, то поле Content-Length должно быть равно числу октетов, переданных в теле сообщения.

3xx. Коды перенаправления:

Данный класс указывает на то, что клиенту для успешного выполнения требуемого запроса потребуются дополнительные действия. Обработка действий зависит от клиентского приложения, но выполнение данного действия без ведома конечного пользователя может быть предпринято только при использовании методов GET и HEAD.

301: Навсегда перемещен (Moved Permanently)

Ресурс, который был запрошен, получил новый URI, в таком случае следует перенаправлять запросы на указанный в ответе новый URI. В случае, когда новый URI является расположением ресурса, а не самим ресурсом, то в ответе нужно указать в поле Location новый URL.

Когда код 301 получен в ответе к запросу, не являющимся GET или HEAD, приложение клиента должно предложить выбор действий, не делая автоматического перенаправления.

Характеристики

Список файлов ВКР