Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Имеется 5 значений первой цифры:

- 1xx: Информационные коды - запрос получен, продолжается обработка.

- 2xx: Успешные коды - действие было успешно получено, понято и обработано.

- 3xx: Коды перенаправления - для выполнения запроса должны быть предприняты дальнейшие действия.

- 4xx: Коды ошибок клиента - запрос имеет плохой синтаксис или не может быть выполнен.

- 5xx: Коды ошибок сервера - сервер не в состоянии выполнить правильный запрос.

Конкретные значения числовых кодов состояния, определенных в HTTP/1.1, и примерный набор соответствующих поясняющих фраз (Reason-Phrase) приводятся ниже. Поясняющие фразы (Reason-Phrase), перечисленные здесь являются рекомендуемыми, но могут быть заменены на эквивалентные не влияя на протокол.

Status-Code = "100" ; Продолжать, Continue |

"101" ; Переключение протоколов, ; Switching Protocols |

"200" ; OK |

"201" ; Создан, Created |

"202" ; Принято, Accepted |

"203" ; Не авторская информация, ; Non-Authoritative Information |

"204" ; Нет содержимого, No Content |

"205" ; Сбросить содержимое, Reset ; Content |

"206" ; Частичное содержимое, Partial ; Content |

"300" ; Множественный выбор, Multiple ; Choices |

"301" ; Постоянно перемещен, Moved ; Permanently |

"302" ; Временно перемещен, Moved ; Temporarily |

"303" ; Смотреть другой, See Other |

"304" ; Не модифицирован, Not Modified |

"305" ; Используйте прокси-сервер, Use ; Proxy |

"400" ; Испорченный запрос, Bad Request |

"401" ; Несанкционированно, Unauthorized |

"402" ; Требуется оплата, Payment ; Required |

"403" ; Запрещено, Forbidden |

"404" ; Не найден, Not Found |

"405" ; Метод не допустим, Method Not ; Allowed |

"406" ; Не приемлем, Not Acceptable |

"407" ; Требуется установление ; подлинности через прокси-сервер, ; Proxy Authentication Required |

"408" ; Истекло время ожидания запроса, ; Request Timeout |

"409" ; Конфликт, Conflict |

"410" ; Удален, Gone |

"411" ; Требуется длина, Length Required |

"412" ; Предусловие неверно, ; Precondition Failed |

"413" ; Объект запроса слишком большой, ; Request Entity Too Large |

"414" ; URI запроса слишком длинный, ; Request-URI Too Long |

"415" ; Неподдерживаемый медиатип, ; Unsupported Media Type |

"500" ; Внутренняя ошибка сервера, ; Internal Server Error |

"501" ; Не реализовано, Not Implemented |

"502" ; Ошибка шлюза, Bad Gateway |

"503" ; Сервис недоступен, Service ; Unavailable |

"504" ; Истекло время ожидания от шлюза, ; Gateway Timeout |

"505" ; Не поддерживаемая версия HTTP, ; HTTP Version Not Supported | extension-code

extension-code = 3DIGIT

Reason-Phrase = *<TEXT не включающий CR, LF>

Коды состояния HTTP расширяемы. HTTP приложениям не требуется понимать значение всех зарегистрированных кодов состояния, хотя их понимание очень желательно. Приложения должны понимать класс любого кода состояния, который обозначается первой цифрой, и обрабатывать любой нераспознанный ответ как эквивалентный коду состояния x00 этого класса, за исключением тех случаев, когда нераспознанный ответ не должен кэшироваться. Например, если клиентом получен и не был распознан код состояния 431, то он может безопасно считать, что в запросе что-то было неправильно и обрабатывать ответ, как если бы был получен код состояния 400. В таких случаях агентам пользователя следует представить пользователю объект, возвращенный в ответе, так как этот объект, вероятно, включает читабельную для человека информацию, которая поясняет необычное состояние.

6.2 Поля заголовка ответа.

Поля заголовка ответа (response-header fields) позволяют серверу передавать дополнительную информацию об ответе, которая не может быть помещена в строку состояния Status-Line. Эти поля заголовка дают информацию о сервере и о дальнейшем доступе к ресурсу, указанному этим Request-URI.

response-header = Age | Location | Proxy-Authenticate | Public | Retry-After | Server | Vary | Warning | WWW-Authenticate

Множество имен полей заголовка ответа (Response-header) может быть надежно расширенО только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику полей заголовка ответа (Response-header), если все стороны соединения распознают их как поля заголовка ответа (Response-header). Нераспознанные поля заголовка обрабатываются как поля заголовка объекта (entity-header).

7 Объект (Entity).

Сообщения запросов и ответов могут передать объект, если это не запрещено методом запроса или кодом состояния ответа. Объект состоит из полей заголовка объекта (entity-header) и тела объекта (entity-body), хотя некоторые ответы могут включать только заголовки объекта (entity-headers).

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

7.1 Поля заголовка объекта.

Поля заголовка объекта (Entity-header fields) определяют опциональную метаинформацию о теле объекта (entity-body) или, если тело отсутствует, о ресурсе, идентифицированном запросом.

entity-header = Allow | Content-Base | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | ETag | Expires | Last-Modified | extension-header

extension-header = message-header

Механизм расширения полей заголовка позволяет вводить дополнительные поля заголовка объекта (entity-header fields) не изменяя протокол, но эти поля могут быть и не распознаны получателем. Получатель должен игнорировать нераспознанные поля заголовка, а прокси-сервер должен просто пересылать их без изменений.

7.2 Тело объекта.

Тело объекта (если оно присутствует) посылается с HTTP запросом или ответом и имеет формат и кодирование, определяемое полями заголовка объекта (entity-header fields).

entity-body = *OCTET

Тело объекта (entity-body) представлено в сообщении только тогда, когда присутствует тело сообщения (message-body). Тело объекта (entity-body) получается из тела сообщения (message-body) декодированием любого кодирования передачи, указанного в поле Transfer-Encoding, которое может быть применено для гарантирования безопасной и правильной передачи сообщения.

7.2.1 Тип.

Когда в сообщении содержится тело объекта (entity-body), тип данных этого тела определяется полями заголовка Content-Type и Content-Encoding. Они определяют двухуровневую упорядоченную модель кодирования: