Понятие протокола, и связанные с ним понятия
| Вид материала | Документы |
- Программа курса лекций, 33.31kb.
- А, а также связанные с этим сервисы, частично или полностью через пакетные сети, 211.32kb.
- Тема Основные понятия о правовых явлениях, 165.32kb.
- Контрольная работа по предмету «Логика», 57.32kb.
- Понятия налоги и налогообложение. Налоговая система понятие налога и сбора. Принципы, 2182.16kb.
- Задачи: Продолжить формирование понятия о внутренней среде и ее компонентах. Раскрыть, 161.91kb.
- Естественные науки 14 апреля с 10. 00 до 17., 82.95kb.
- Словари профессий, 47.56kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 114.5kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 107.69kb.
Другие протоколы прикладного уровня стека TCP/IP.
Протокол FTP.
FTP – File Transfer Protocol, RFC-959 – протокол передачи файлов, наряду с протоколами передачи электронной почты и удаленного управления, один из старейших протоколов прикладного уровня стека TCP/IP. Практически уже к 1985 году, то есть ко времени появления первых полнофункциональных реализаций стека TCP/IP, он уже обрел современный вид, первые же реализации отностятся к началу 70-х годов, т.е. к тому времени, когда Internet еще был ARPANETом.
Протокол FTP, как следует из его названия, предназначен для передачи файлов, при этом FTP-сервер представляет доступные для клиента файлы в виде традиционного дерева каталогов файловой системы, по которой можно перемещаться командами смены каталогов, просматривать каталоги командой LIST, загружать файлы или группы файлов командами GET/MGET с удаленной машины на локальную и командами PUT/MPUT – в обратном направлении.
Особенностью протокола FTP является использование раздельных каналов для управления и передачи файлов. Канал управления образуется традиционным образом – пассивное открытие со стороны сервера (по умолчанию порт 21), активное со стороны клиента, тип сервиса – минимум задержки, по нему передаются короткие текстовые команды и ответы на них (тоже алфавитно-цифровые). В то же время каналы для передачи файлов открываются по мере необходимости, и используют тип сервиса «максимизация пропускной способности».
После установления TCP соединения клиент производит процедуру аутетнтификации, особенностью которой является передача имени пользователя и пароля в оригинальном виде, без какой-либо кодировки – протокол FTP создавался тогда, когда сетевые взломщики всех мастей были персонажами фантастической литературы. Многие FTP серверы допускают так называемый анонимный доступ (имя пользователя ANONIMUS, в качестве пароля используется адрес электронной почты). После авторизации возможен обмен командами/откликами, в ходе которого клиент может просматривать содержимое каталогов, менять текущие локальный и удаленный каталоги и т.д.
После того, как нужные файлы найденны, клиент в пассивном режиме открывает порт для обмена данными, и сообщает его номер серверу командой PORT. Сервер обычно использует для соединения данных порт 20. При необходимости для одного файла можно открыть несколько соединений, указав для каждого смещение относительно начала файла. С одной стороны, такая схема придает протоколу значительную гибкость, вплоть до установления соединения данных между двумя системами, ни одна из которых не является машиной клиента. С другой стороны, схема с пассивным открытием соединения данных со стороны клиента создает проблемы при работе через NAT или Firewall. В первом случае клиент не знает, на какой порт и адрес будет отображен его порт за NAT, во втором – может быть запрещено открытие входящих соединений извне. В этом случае выходом может быть интеграция функциональности прокси-сервера в сервер NAT или Firewall. NAT или Firewall будет в этом случае работать с внешним FTP сервером по FTP протоколу, а с клиентским узлом, возможно, и по другому протоколу, например, HTTP.
Протокол HTTP.
Протокол HTTP (Hyper Text Transfer Protocol, RFC-1945,2616,2617), как следует из его названия, тесным образом связан с гипертекстом (HTML), являющимся основой WWW. Название протокола никоим образом не означает, что он предназначен ТОЛЬКО для передачи гипертекста, а означает именно интеграцию с гипертекстом.
Соответственно, объектом запроса в этом протоколе выступает характерный для гипертекста Uniform Resource Locators (URL). Как и в случае гипертекста, он может быть абсолютным (начинается с остельным. В последнем случае для формирования абсолютного URL используется информация из поля Host:. Заметим, что если в случае FTP объектом запроса был ФАЙЛ, то в случае HTTP файла, соответствующего запрашиваемому URL может и не быть, более того, если в URL присутствует модификатор запроса (?), файла с таким именем просто не может существовать. В этом случае файл, передаваемый в ответ на запрос, формируется динамически с учетом URL и, возможно, другой информации, присутствующей в запросе.
Запрос, передаваемый HTTP клиентом серверу, представляет собой последовательность текстовых строк, завершающейся пустой строкой. Пустая строка завершает ЗАГОЛОВОК запроса, некоторые запросы помимо заголовка содержат ТЕЛО, следующее за пустой строкой. Тело интерпретируется в зависимости от типа запроса. Первая строка заголовка запроса определяет тип запроса, в терминах HTTP называемый МЕТОДОМ, запрашиваемый URL (вместо URL может стоять *, если запрос относится не к конкретному URL, а ко всему серверу) и версию HTTP. Последующие содержат дополнительную информацию, которая позволяет серверу подобрать ответ в соответствии с возможностями и предпочтениями клиента. Это может быть информация о типе клиента (User-Agent), предпочтительном языке (Accept-Language), кодировках (Accept-Charset), поддерживаемых форматах данных (Accept), допустимом кодировании (Accept-Encoding), о промежуточных прокси-серверах, через которые должен пройти запрос и ответ на него (Via, Max-Forwards), и других особенностях обработки запроса.
В настоящее время определенны следующие методы HTTP:
OPTIONS представляет собой запрос информации о коммуникационных опциях, доступных в цепочке запрос/отклик, идентифицированной URL. Если URL тождественен символу звездочка ("*"), то запрос OPTIONS будет относиться ко всему серверу. Если URL не равен звездочке, запрос OPTIONS относится только к опциям, которые доступны при обмене с данным ресурсом. Этот метод позволяет клиенту определить опции и/или требования, связанные с ресурсами, или возможности сервера, не прибегая к операциям по извлечению и пересылке каких-либо файлов.
Если отклик сервера не сигнализирует об ошибке, отклик не должен включать никакой информации об объекте, отличной оттого, что считается коммуникационными опциями (напр., Allow подходит под эту категорию, а Content-Type нет). Отклики на этот метод не должны кэшироваться.
Отклик 200 должен включать в себя любые поля заголовка, которые указывают на опционные характеристики используемого сервера (например, Public), включая любые расширения неопределенные в данной спецификации, в дополнение к любым общим используемым полям заголовка. Отклик 200 должен включать любые поля заголовка, которые указывают опционные характеристики используемого сервера и применимы к данному ресурсу (напр., Allow), включая любые расширения, не описанные в данной спецификации. Если запрос OPTIONS проходит через прокси, то он должен редактировать отклик и удалять те опции, которые не доступны для реализации через данный прокси-сервер.
Метод GET предполагает извлечение любой информации (в форме объекта), заданной URL. Если URL относится к процессу, генерирующему данные, то в результате в виде объекта будут присланы эти данные, а не исходный текст самого процесса, если только этот текст не является результатом самого процесса.
Семантика метода меняется на "условный GET", если сообщение-запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Условный GET запрашивает пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на "частичный GET", если сообщение запроса включает в себя поле заголовка Range. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей, либо на ускорение обмена за счет открытия для одного объекта нескольких соединений.
Отклик на запрос GET буферизуется тогда и только тогда, когда это согласуется с требованиями буферизации.
Метод HEAD идентичен GET за исключением того, что сервер не должен присылать тело сообщения. Метаинформация, содержащаяся в заголовках отклика на запрос HEAD должна быть идентичной информации посланной в отклик на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, указанном в запросе, без передачи тела самого объекта. Этот метод часто используется для тестирования гипертекстных связей на корректность, доступность и актуальность.
Отклик на запрос HEAD может кэшироваться в том смысле, что информация, содержащаяся в отклике, может использоваться для актуализации кэшированных ранее объектов данного ресурса. Если новые значения поля указывают на то, что кэшированный объект отличается от текущего объекта (как это индицируется изменением Content-Length, Content-MD5, ETag или Last-Modified), тогда запись в кэше должна рассматриваться как устаревшая.
Методы GET и HEAD должны поддерживаться всеми серверами. Остальные методы являются опционными.
Метод POST используется при заявке серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного URL. POST создан для обеспечения однородной схемы реализации следующих функций:
- Аннотация существующего ресурса;
- Помещение сообщения на электронную доску объявлений, в группу новостей, почтовый список или какую-то другую группу статей;
- Выдача блока данных, такого как при передаче формы процессу ее обработки;
- Расширение базы данных с помощью операции добавления (append).
Реальная операция, выполняемая методом POST, определяется сервером и обычно зависит от URL. Присланный объект является данными, с которыми будет работать ресурс, идентифицированный URL.
Метод PUT требует, чтобы вложенный объект был запомнен с использованием URL. Если URL относится к уже существующему ресурсу, то вложенный объект следует рассматривать как модифицированную версию объекта на исходном сервере. Если URL не указывает на существующий ресурс и запрашивающий агент пользователя может определить этот URL как новый ресурс, исходный сервер может создать ресурс с этим URL. Если новый ресурс создан, исходный сервер должен информировать об этом агента пользователя, послав код отклик 200 (OK) или 204 (No Content - никакого содержимого) и тем самым, объявляя об успешно выполненном запросе. Если ресурс не может быть создан или модифицирован с помощью URL, должен быть послан соответствующий код отклика, который отражает характер проблемы. Получатель объекта не должен игнорировать любой заголовок Content-* (например, Content-Range), который он не понял или не использовал, а должен в таком случае вернуть код отклика 501 (Not Implemented - не использовано).
Если запрос проходит через кэш и URL идентифицирует один или более кэшированных объектов, эти объекты должны рассматриваться как устаревшие. Отклики этого метода не должны кэшироваться.
Фундаментальное отличие между запросами POST и PUT отражается в различных значениях URL. URL в запросе POST идентифицирует ресурс, который будет работать со вложенным объектом. Этот ресурс может быть процессом приемки данных, шлюзом к другому протоколу или отдельным объектом, который воспринимает аннотации. Напротив, URL в запросах PUT идентифицируют объекты, заключенные в запросе, – агент пользователя знает, какой URL применить и сервер не должен пытаться посылать запрос другому ресурсу. Если сервер хочет, чтобы запрос был направлен другому URL, он должен послать отклик 301 (Moved Permanently). Агент пользователя может принять свое собственное решение относительно того, следует ли переадресовывать запрос.
Метод DELETE требует, чтобы исходный сервер уничтожил ресурс, идентифицируемый URL. Этот метод на исходном сервере может быть отвергнут вмешательством человека (или каким-то иным путем). Клиент не может гарантировать, что операция была выполнена, даже если возвращенный статусный код указывает, что операция завершилась успешно. Однако, сервер не должен сообщать об успехе, если за время отклика он не намерен стереть ресурс или переместить его в недоступное место.
Сообщение об успехе должно иметь код 200 (OK), если отклик включает объект, описывающий статус; 202 (Accepted – принято), если операция еще не произведена или 204 (No Content – Никакого содержимого), если отклик OK, но объекта в нем нет.
Если запрос проходит через кэш, а URL идентифицирует один или более кэшированных объектов, эти объекты следует считать устаревшими (stale). Отклики на этот метод не кэшируемы.
Метод TRACE используется для того, чтобы запустить удаленный цикл сообщения-запроса на прикладном уровне. Конечный получатель запроса должен отослать полученное сообщение назад клиенту в виде тела объекта (код = 200 (OK)). Конечным получателем является либо исходный сервер, либо первый прокси или шлюз для которого получено значение Max-Forwards=0 (ненулевое значение Max-Forwards каждым сервером уменьшается на 1) в запросе. Запрос TRACE не должен включать в себя объект.
TRACE позволяет клиенту видеть, что получено на другом конце цепи запроса и использовать эти данные для тестирования или диагностики. Значение поля заголовка Via представляет особый интерес, так как оно позволяет отследить всю цепочку запроса. Использование поля заголовка Max-Forwards позволяет клиенту ограничить длину цепи запроса, которая полезна для тестирования цепи прокси, переадресующих сообщения по замкнутому кругу.
В случае успеха отклик должен содержать все сообщение-запрос с Content-Type = "message/http". Отклики этого метода не должны кэшироваться.
Метод CONNECT позволяет агенту пользователя установить TCP-соединение чере прокси-сервер (фаервол) с удаленным узлом. Передаваемые по этому соединению данные впоследствии не анализируются и не изменяются прокси-сервером. Используется, в частности, для установления безопасных соединений с шифрованием данных, передаваемых транспортным уровнем, так называемых SSL (Soket Security Link) или TLS (Transport Level Security).
Отклики сервера начинаются со строки HTTP
Коды результата (статусные коды) – трехзначные десятичные числа, определяющие успешность проведения требуемой операции. Первая цифра определяет класс отклика, две последующие конкретизируют его. Статусные коды HTTP следующие:
Информационный 1xx Этот класс статусного кода индицирует информационный отклик, состоящий только из статусной строки и опционных заголовков с пустой строкой в конце. HTTP/1.0 не определяет каких-либо статусных кодов 1xx, серверы не должны посылать отклики 1xx клиентам HTTP/1.0 за исключением случаев отладки экспериментальных протокольных версий.
100 Continue (продолжение) Клиент может продолжать работу, получив этот отклик. Этот промежуточный отклик используется для информирования клиента о том, что начальная часть запроса получена и пока не отклонена сервером. Клиенту следует продолжить отправлять оставшуюся часть запроса, если же запрос уже отправлен, то игнорировать этот отклик. Сервер должен послать окончательный отклик по завершении реализации запроса.
101 Switching Protocols (Переключающие протоколы) Сервер оповещает клиента о том, что он понял и принял к исполнению запрос. С помощью поля заголовка сообщения Upgrade (раздел 13.41) клиент уведомляется об изменении прикладного протокола для данного соединения. Сервер переходит на протокол, определенный в поле заголовка отклика Upgrade, немедленно после получения пустой строки, завершающей отклик 101. Протокол следует изменять лишь в случае, если он предоставляет существенные преимущества.
Successful 2xx (Успешная доставка) Этот класс статусного кода индицирует, что запрос клиента благополучно получен, понят и принят к исполнению.
200 OK Запрос успешно исполнен. Информация, возвращаемая вместе с откликом, зависит от метода, использованного запросом, например:
GET – в качестве отклика посылается объект, соответствующий запрошенному ресурсу;
HEAD – в качестве отклика посылаются поля заголовка объекта (без какого-либо тела), соответствующего запрошенному ресурсу;
POST – объект, описывающий или содержащий результат операции;
TRACE – объект, содержащий сообщение-запроса, в виде, полученном оконечным сервером.
201 Created (Создано) – Запрос исполнен и в результате создан новый ресурс. Вновь созданный ресурс может быть доступен через URL, присланный в объекте отклика, со значащей частью URL ресурса в поле заголовка Location. Исходный сервер должен создать ресурс до отправки статусного кода 201. Если операция не может быть выполнена немедленно, сервер вместо этого должен откликнуться статусным кодом 202 (Accepted).
202 Accepted (Принято) – Запрос был принят для исполнения, но обработка запроса не завершена. Запрос может обрабатываться или нет, так как он был блокирован в процессе исполнения. Не существует механизма повторной посылки статусного кода для асинхронных операций вроде этой.
Целью отклика 202 является разрешить серверу принять запрос для некоторого другого процесса (возможно процесса, запускаемого раз в день), не требуя того, чтобы соединение агента пользователя с сервером сохранялось до завершения процесса. Объект, возвращаемый этим откликом должен включать в себя текущий статус запроса и указатель на статус-монитор или некоторую оценку того, когда пользователь может ожидать завершения реализации запроса.
203 Non-Authoritative Information (Не надежная информация) – Присылаемая в ответ метаинформация в заголовке объекта не идентифицируется, как полученная от исходного сервера, ее следует скорее считать косвенной, полученной опосредовано. Например, включение местной аннотационной информации о ресурсе может иметь последствия для мета информации, известной исходному серверу. Использование данного кода отклика не является обязательным и целесообразно лишь в случае, когда отклик мог бы быть равен 200 (OK).
204 No Content (Никакого содержимого) – Сервер исполнил запрос, но нет никакой новой информации для отсылки. Этот отклик первоначально предназначался для разрешения ввода, не вызывая изменения активного документа агента пользователя. Отклик может включать новую метаинформацию в форме заголовков объектов, которая должна быть передана для документа, отображаемого агентом пользователя. Отклик 204 не должен включать тела сообщения и всегда завершается пустой строкой после полей заголовка.
205 Reset Content (Сброс содержимого) – Сервер исполнил запрос и агент пользователя должен вернуть документ к виду, который он имел в момент посылки запроса. Этот отклик первоначально предназначался для обеспечения ввода при выполнении пользователем операции, за которой следует очистка формы, в которую произведен ввод, так что пользователь может начать другую операцию ввода. Отклик не должен включать в себя объект.
206 Partial Content (Частичное содержимое) – Сервер исполнил частичный запрос GET для заданного ресурса. Запрос должен включать поле заголовка Range, указывающее на желательный интервал (range). Отклик должен включать поле заголовка Content-Range, указывающее диапазон данных, включенных в отклик, или множественные байтные интервалы (multipart/byteranges) Content-Type, включающие поля Content-Range для каждой из частей. Если множественные байтные интервалы не используются, поле заголовка Content-Length в отклике должно соответствовать действительному числу октетов в теле сообщения. Кэш, который не поддерживает заголовки Range и Content-Range, не должен кэшировать отклики 206 (Partial).
Redirection 3xx (Переадресация) – Этот класс статусных кодов указывает, что для выполнения запроса, нужны дальнейшие действия агента пользователя. Необходимые действия могут быть выполнены агентом пользователя без взаимодействия с пользователем, тогда и только тогда, когда используемый метод соответствует GET или HEAD. Агент пользователя не должен автоматически переадресовывать запрос более чем 5 раз, так как такая переадресация обычно свидетельствует о зацикливании запроса.
300 Multiple Choices (Множественный выбор) – Запрошенный ресурс соответствует какому-то представлению из имеющегося набора представлений, каждое со своим адресом. Имеется информация, полученная в результате согласования под управлением агента пользователя, так что пользователь (или агент пользователя) может выбрать предпочтительное представление и переадресовать свой запрос по соответствующему адресу.
Если это только не был запрос HEAD, отклик должен включать объект, содержащий список характеристик ресурсов и их адресов, из которых пользователь или агент пользователя может выбрать наиболее подходящий. Формат объекта специфицируется типом среды, заданным полем заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, выбор наиболее подходящего варианта может быть выполнен автоматически. Однако спецификация HTTP не определяет какого-либо стандарта для такого автоматического выбора.
Если сервер имеет предпочтительный вариант представления, ему следует включить соответствующий URL этого представления в поле Location. Агент пользователя может использовать значение поля Location для реализации автоматического выбора. Этот отклик может кэшироваться, если не указано обратного.
301 Moved Permanently (Постоянно перемещен) – Запрошенному ресурсу был приписан новый постоянный URL и любая будущая ссылка на этот ресурс должна делаться с использованием одного из присланных URL. Клиенты с возможностью редактирования связей должны, где возможно, автоматически менять связи для ссылок Request-URI на одну или более новых ссылок, присланных сервером. Этот отклик можно кэшировать, если не указано обратного.
Если новый URI является адресом (location), его URL должен быть задан в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.
Если получен статусный код 301 в ответ на запрос, отличный от GET или HEAD, агент пользователя не должен автоматически переадресовывать запрос, если только это не может быть подтверждено пользователем, так как такая переадресация может изменить условия, при которых направлен запрос.
302 Moved Temporarily (Временно перемещен) – Запрошенный ресурс размещается временно под различными URI. Так как переадресация может быть случайно изменена, клиент должен продолжать использовать Request-URI для будущих запросов. Этот отклик допускает кэширование, если имеются соответствующие указания в полях заголовка Cache-Control или Expires.
Если новый URI является адресом (location), его URL должен задаваться полем Location отклика. Если запрошенный метод не HEAD, объект отклика должен содержать короткое гипертекстное замечание с гиперсвязью, указывающей на новый URI.
Если в ответ на запрос, отличный от GET или HEAD, получен статусный код 302, агент пользователя не должен автоматически переадресовывать запрос, если это не может быть подтверждено пользователем, так как это может изменить условия, при которых был выдан запрос.
303 See Other (смотри другие) – Отклик на запрос может быть найден под разными URI. Его следует извлекать с помощью метода GET. Этот метод первоначально создан для того, чтобы позволить переадресацию агента пользователя на выбранный ресурс при запуске скрипта с помощью POST. Новый URI не является заменой ссылки для первоначально запрошенного ресурса. Отклик 303 не кэшируется, но отклик на второй (переадресованный) запрос может кэшироваться.
Если новый URI является адресом (location), его URL должно быть задано в поле Location отклика. Если метод запроса не HEAD, объект отклика должен содержать гипертекстовую ссылку на новый URI.
304 Not Modified (Не модифицировано) – Если клиент выполнил условный запрос GET и получил доступ, а документ не был модифицирован, сервер должен реагировать этим статусным кодом. Отклик не должен содержать тела сообщения.
Отклик должен включать поля заголовка:
Дата
ETag и/или Content-Location, если заголовок был послан в рамках отклика 200 на тот же самый запрос
Expires, Cache-Control и/или Vary, если значение поля может отличаться от посланного в каком-либо предыдущем отклике того же типа
Если кэш использует полученный отклик 304 для актуализации записи в кэше, то кэш должен выполнить актуализацию с учетом новых значений полей, присланных в отклике.
Отклик 304 не должен включать в себя тело сообщения и, по этой причине всегда завершается пустой строкой после полей заголовка.
305 Use Proxy (Используйте прокси) – Запрошенный ресурс должен иметь доступ через прокси-сервер, указанный в поле Location. Поле Location задает URL прокси-сервера. Предполагается, что получатель повторит запрос через прокси.
Client Error 4xx (Ошибка клиента) – Класс статус кодов 4xx предназначен для случаев, когда клиент допустил ошибку. За исключением случая отклика на запрос HEAD, серверу следует включить объект, содержащий объяснение ошибочной ситуации, а также указать, является ли ситуация временной или постоянной. Эти статусные коды применимы к любому методу запросов. Агенту пользователя следует отобразить все объекты.
Замечание. Если клиент посылает данные, реализация сервера, использующая протокол TCP, должна позаботиться о том, чтобы клиент получил пакет, содержащий отклик, до того как сервер закроет данное соединение. Если клиент продолжает посылку данных серверу после закрытия связи, TCP-уровень сервера должен послать клиенту пакет reset (сброс), который может стереть содержимое входного буфера клиента до того, как оно будет прочитано и интерпретировано приложением HTTP.
400 Bad Request (Плохой запрос) – Запрос может быть не понят сервером из-за ошибочного синтаксиса. Клиенту не следует повторять запрос без модификации.
401 Unauthorized (Не авторизован) – Запрос требует авторизации пользователя. Отклик должен включать в себя поле заголовка WWW-Authenticate (раздел 13.46), содержащее требование (challenge), применимое к запрошенному ресурсу. Клиент может повторить запрос с соответствующим содержимым поля заголовка Authorization. Если запрос уже включал допуск в поле Authorization, тогда отклик 401 указывает на то, что данный допуск не работает. Если отклик 401 содержит то же требование, что и предшествующий отклик, а агент пользователя уже пробовал пройти идентификацию по крайней мере хотя бы раз, тогда пользователю следует предоставить объект, содержащийся в отклике, так как он может содержать полезную диагностическую информацию.
402 Необходима оплата – Этот код зарезервирован для использования в будущем.
403 Forbidden (Запрещено) – Сервер понял запрос, но отказался его исполнить. Авторизация не поможет и повторять запрос не следует. Если метод запроса не HEAD, а сервер желает открыто объявить причину неисполнения запроса, то ему следует описать соображения, по которым запрос отклонен Этот статусный код обычно используется, когда сервер не хочет показывать, почему запрос отклонен, или когда другой отклик не подходит.
404 Not Found (Не найдено) – Сервер не нашел ничего, отвечающего Request-URI. Не приводится никаких данных о том, являются ли эта ситуация временной или постоянной. Если сервер не хочет сделать эту информацию открытой для клиента, вместо этого может использоваться статусный код 403. Статусный код 410 (Gone - Утрачен) следует использовать, если сервер знает за счет некоторого внутреннего механизма конфигурации, что старый ресурс постоянно недоступен и не имеет нового адреса его размещения.
405 Method Not Allowed (Метод не разрешен) – Метод, специфицированный в Request-Line, не разрешен для ресурса, указанного Request-URI. Отклик должен включать заголовок Allow, содержащий список разрешенных методов для запрошенного ресурса.
406 Not Acceptable (Не приемлемо) – Ресурс, идентифицированный запросом, способен генерировать только объекты откликов, которые имеют характеристики, неприемлемые согласно заголовкам accept, присланным в запросе. Если это не запрос HEAD, отклик должен включать объект, содержащий список доступных характеристик объекта и адреса, где пользователь или агент пользователя может выбрать нечто наиболее подходящее. Формат объекта специфицируется типом среды, приведенным в поле заголовка Content-Type. В зависимости от формата и возможностей агента пользователя, оптимальный выбор может быть сделан автоматически. Но спецификация HTTP не определяет какого-либо стандарта для такого автоматического выбора.
Замечание. HTTP/1.1 серверам разрешено присылать отклики, которые неприемлемы согласно заголовкам accept, присланным в запросе. В некоторых случаях, может оказаться предпочтительнее послать отклик 406. Агенты пользователя могут просматривать заголовки приходящих откликов с тем, чтобы определить, являются ли они приемлемыми. Если отклик не может быть воспринят, агенту пользователя следует временно прервать прием данных и запросить пользователя принять решение о дальнейших действиях.
407 Proxy Authentication Required (Необходима идентификация прокси) – Этот статусный код подобен 401 (Unauthorized), но указывает, что клиент должен сначала авторизоваться на прокси-сервере. Прокси должен прислать в ответ поле заголовка Proxy-Authenticate, содержащего требования, реализуемые на прокси для запрошенного ресурса. Клиент может повторить запрос с подходящим полем заголовка Proxy-Authorization.
408 Request Timeout (Таймаут запроса) – Клиент не выдал запрос в пределах временного интервала, в течение которого сервер его ожидал. Клиент может повторить запрос без модификаций в любое время.
409 Conflict (Конфликт) – Выполнение запроса не может быть завершено из-за конфликта с текущим состоянием ресурса. Этот статусный код разрешен в ситуациях, где предполагается, что пользователь может разрешить конфликт и повторно послать запрос. Тело отклика должно включать достаточно информации, чтобы пользователь мог понять причину конфликта. В идеале, объект отклика должен был бы включать достаточно информации для пользователя или агента пользователя для того, чтобы уладить конфликт, однако это невозможно и необязательно.
Конфликты наиболее вероятно происходят в результате запроса PUT. Если задействована версия и объект операции PUT вызывает изменение ресурса, которые конфликтуют с изменениями внесенными запросом, выполненным ранее, сервер может использовать отклик 409 для того, чтобы указать на невозможность завершить выполнение запроса. В этом случае объект отклика должен содержать список отличий между двумя версиями формата, определенном откликом Content-Type.
410 Gone (Исчез) – Запрошенный ресурс не является более доступным на сервере и не известен указатель переадресации. Это условие следует считать постоянным. Клиенты с возможностями редактирования связей должны ликвидировать ссылки на объект после подтверждения пользователем. Если сервер не знает или не имеет возможности определить, является ли данное условие постоянным или временным, следует использовать отклик со статусным кодом 404 (Not Found). Этот отклик можно кэшировать, если не указано обратного.
Отклик 410 первоначально предназначался для того, чтобы помочь работе задач в WWW-среде путем сообщения получателю о том, что ресурс заведомо недостижим и владелец сервера хотел бы, чтобы связи с этим ресурсом были удалены. Такое событие является типичным для ограниченного периода времени и для ресурсов, принадлежащих частным лицам, которые не работают более с данным сервером. Не обязательно отмечать все постоянно недоступные ресурсы, как исчезнувшие (Gone) или сохранять такую пометку произвольное время – это оставлено на усмотрение собственника сервера.
411 Length Required (Необходима длина) – Сервер отказывается принять запрос без определенного значения Content-Length. Клиент может повторить запрос, если он добавит корректное значение поля заголовка Content-Length, содержащего длину тела сообщения.
412 Precondition Failed (Предварительные условия не выполнены) – Предварительные условия, заданные в одном или более полях заголовка запроса, воспринимаются как не выполненные, когда это проверено сервером. Этот код отклика позволяет клиенту установить предварительные условия для метаинформации (данные поля заголовка) текущего ресурса и, таким образом, предотвратить возможность использования запрошенного метода для ресурса, отличного от указанного.
413 Request Entity Too Large (Объект запроса слишком велик) – Сервер отказывается обрабатывать запрос, потому что объект запроса больше, чем сервер способен обработать. Сервер может закрыть соединение, чтобы помешать клиенту продолжать посылать запросы. Если условие является временным, серверу следует включить поле заголовка Retry-After, чтобы указать на временность этого условия, что означает возможность повторения запроса некоторое время спустя.
414 Request-URI Too Long (URI запроса слишком велик) – Сервер отказывается обслужить запрос, потому что Request-URI длиннее, чем сервер способен интерпретировать. Это редкое обстоятельство может возникнуть только, когда клиент не корректно преобразует запрос POST в GET с длинной информацией запроса. При этом клиент ныряет в "черную дыру" переадресаций. Примером может служить преадресованный URL префикс, который указывает на свой суффикс, или случай атаки сервера клиентом, который пытается использовать дыры в системе безопасности, имеющиеся у клиентов с фиксированной емкостью буферов для работы с Request-URI.
415 Unsupported Media Type (Неподдерживаемый тип среды) – Сервер отказывается обслужить запрос, потому что объект запроса имеет формат, неподдерживаемый запрашиваемым ресурсом для указанного метода.
Ошибка Сервера 5xx – Статусный код отклика, начинающийся с цифры 5, указывает на случаи, когда сервер опасается, что он ошибся или не может реализовать запрос. За исключением случаев, когда обрабатывается запрос HEAD, серверу следует включить объект, содержащий объяснение создавшейся ошибочной ситуации и указывающей на то, является ли ситуация временной или постоянной. Агенту пользователя следует отобразить пользователю любой объект, включенный в отклик. Эти коды откликов применимы для любых методов запроса.
500 Internal Server Error (Внутренняя ошибка сервера) – Сервер столкнулся с непредвиденными условиями, которые мешают ему исполнить запрос.
501 Not Implemented (Не применимо) – Сервер не поддерживает функцию, которая должна быть реализована в ходе исполнения запроса. Это адекватный отклик, когда сервер не распознает метод запроса и не способен поддерживать его для данного ресурса.
502 Bad Gateway (Плохой шлюз) – Сервер при работе в качестве шлюза или прокси получил неверный отклик от вышестоящего сервера, к которому он обратился, выполняя запрос.
503 Service Unavailable (Услуга не доступна) – Сервер в данный момент не может обработать запрос в связи с временной перегрузкой или другими сложившимися обстоятельствами.
Замечание. Существование статусного кода 503 не предполагает, что сервер должен использовать его, когда оказывается перегруженным. Некоторые серверы могут захотеть просто отказаться устанавливать соединение.
504 Gateway Timeout (Таймаут шлюза) – Сервер при работе в качестве внешнего шлюза или прокси-сервера не получил своевременно отклик от вышестоящего сервера, к которому он обратился, пытаясь исполнить запрос.
505 HTTP Version Not Supported (Версия не поддерживается) – Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая была использована в сообщении-запросе. Отклику следует содержать объект, описывающий, почему эта версия не поддерживается и какие другие протоколы поддерживаются сервером.