Полное руководство по настройке http-заголовков для безопасности

Содержание:

Просмотр HTTP-заголовков

2.1. Методы HTTP

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

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

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает «тело» Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса.

2.2. Скрипт для просмотра HTTP-заголовков интересующих интернет-ресурсов

Существует много сервисов, предоставляющих возможность просмотра HTTP-заголовков интересующего вас URL (например, или ).

Но попробуем написать скрипт, позволяющий просматривать заголовки HTTP интересующих интернет-ресурсов (сайтов или страниц), самостоятельно.

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">< head>
< title >Просмотр HTTP-заголовков интересующих Интернет-ресурсов
< meta http-equiv="content-type" content="text/html; charset=utf-8">
< meta http-equiv="content-language" content="ru">< /head>< style>* {
font-family: Arial, Helvetica, sans-serif;
font-size: 12px;}input {
width: 380px;}< /style>< body>
< form action="gh.php?action=exec" method="post">

Введите URI интересующего Интернет-ресурса:

< input type="text" name="uri" value=" if ($uri) { echo $uri; }

else { echo "http://www.domain.ru/"; } ?>">

< input type="submit" name="exec" value="Просмотреть HTTP-заголовок">

Выберите User-Agent:

< select name="user_agent" selected=" echo $user_agent; ?>">


< option value="None" " if ($user_agent == "None") { echo "selected"; } ?>">None


< option value="User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"  	if ($user_agent == "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)") { echo "selected"; } ?>>User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)if ($user_agent == "User-Agent: Yandex/1.03.000 (compatible; Win16; I)") { echo "selected"; } ?>>User-Agent: Yandex/1.03.000 (compatible; Win16; I)	if ($user_agent == "User-Agent: Googlebot/2.1 (+http://www.googlebot.com/bot.html)") { echo "selected"; } ?>>User-Agent: Googlebot/2.1 (+http://www.googlebot.com/bot.html)if ($user_agent == "User-Agent: StackRambler/2.0") { echo "selected"; } ?>>User-Agent: StackRambler/2.0if ($user_agent == "User-Agent: Aport") { echo "selected"; } ?>>User-Agent: Aport

if ($action == exec)

{


// Указываем номер порта соединения


$httpport = 80;


// Удаляем "http://", если URI содержит данную подстроку
$uri = (substr(trim($uri), 0, 7) == "http://") ? substr(trim($uri), 7) : $uri;
// Выделяем из URI домен и страницу (если она присутствует):
//
$res будет содержать имя домена (заканчиваться должен слэшем)
//
$res будет содержать имя страницы (без имени домена)
preg_match("/(w{0,3}.?+.w{2,3})(?=/)/(*)/?/", $uri, $res);
// Открывает сокет соединения указанного домена/страницы
$fp = @fsockopen($res, $httpport);
?>


// Формируем запрос для указанного домена


// Используем метод HEAD


// Если требуется получить в ответе домена "тело" страницы, необходимо использовать метод GET


$query = "HEAD /".$res." HTTP/1.1
";


$query = $query."HOST: ".$res."
";


if ($user_agent  "None")


{



$query = $query.$user_agent."
";


}


$query = $query."Connection: close

";


// Отображаем текст запроса


echo nl2br(htmlspecialchars($query))."";


// Отправляем домену запрос


fputs($fp, $query);


while (!feof($fp))


{



// Получаем ответ от домена (по одной строке)



$s = fgets($fp);



// Выводим ответ домена (также по одной строке)



echo nl2br(htmlspecialchars($s));


}


// Закрываем соединение


fclose($fp);

}
?>< /body>

浏览器兼容性

The compatibility table in this page is generated from structured data. If you’d like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

Update compatibility data on GitHub

	Chrome	Edge	Firefox	Internet Explorer	Opera	Safari	Android webview	Chrome for Android	Firefox for Android	Opera for Android	Safari on iOS	Samsung Internet
	Chrome Full support Yes	Edge Full support 12	Firefox Full support Yes	IE Full support Yes	Opera Full support Yes	Safari Full support Yes	WebView Android Full support Yes	Chrome Android Full support Yes	Firefox Android Full support Yes	Opera Android Full support Yes	Safari iOS Full support Yes	Samsung Internet Android Full support Yes

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

Страница сгенерирована в nginx 1.10.2;
Это обычная html страница (text/html);
Размер страницы 102452 байт или 100 кб;
Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
Страница может храниться в любом кэше (public) на протяжении часа (expires);

Таким способом может быть выполнена проверка http заголовков для любой страницы или ресурса чтобы сразу определить все ли отправляется правильно. Например, посмотрим заголовки для изображения:

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй — по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

Затем отправим полученную сумму с заголовком:

И снова мы должны получить ответ 304, страница не изменена.

Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Security

Controls resources the user agent is allowed to load for a given page.

Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP request to the specified URI.

Associates a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.

Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.

Force communication using HTTPS instead of HTTP.

Enables cross-site scripting filtering.

Redirected Input

The universal method for passing request data is through redirected
(standard input)—piping. Such data is buffered and then with no further
processing used as the request body. There are multiple useful ways to use
piping:

Redirect from a file:

$ http PUT httpbin.org/put X-API-Token:123 < files/data.json

Or the output of another program:

$ grep '401 Unauthorized' /var/log/httpd/error_log | http POST httpbin.org/post

You can use for simple data:

$ echo '{"name": "John"}' | http PATCH httpbin.org/patch X-API-Token:123

You can also use a Bash here string:

$ http httpbin.org/post <<<'{"name": "John"}'

You can even pipe web services together using HTTPie:

$ http GET https://api.github.com/repos/jakubroztocil/httpie | http POST httpbin.org/post

You can use to enter multiline data on the terminal:

$ cat | http POST httpbin.org/post
<paste>
^D

$ cat | http POST httpbin.org/post Content-Type:text/plain
- buy milk
- call parents
^D

On OS X, you can send the contents of the clipboard with :

$ pbpaste | http PUT httpbin.org/put

Passing data through cannot be combined with data fields specified
on the command line:

$ echo 'data' | http POST example.org more=data   # This is invalid

To prevent HTTPie from reading data you can use the
option.

语法

作为消息主体中的消息头

在HTTP场景中，第一个参数或者是（默认值，表示回复中的消息体会以页面的一部分或者整个页面的形式展示），或者是（意味着消息体应该被下载到本地；大多数浏览器会呈现一个“保存为”的对话框，将的值预填为下载后的文件名，假如它存在的话）。

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"

作为multipart body中的消息头

在HTTP场景中。第一个参数总是固定不变的；附加的参数不区分大小写，并且拥有参数值，参数名与参数值用等号(=)连接，参数值用双引号括起来。参数之间用分号(;)分隔。

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

指令

后面是一个表单字段名的字符串，每一个字段名会对应一个子部分。在同一个字段名对应多个文件的情况下（例如，带有属性的元素），则多个子部分共用同一个字段名。如果name参数的值为，意味着这个子部分表示的不是一个HTML字段，而是在未明确指定字符集信息的情况下各部分使用的默认字符集。; 后面是要传送的文件的初始名称的字符串。这个参数总是可选的，而且不能盲目使用：路径信息必须舍掉，同时要进行一定的转换以符合服务器文件系统规则。这个参数主要用来提供展示性信息。当与一同使用的时候，它被用作»保存为»对话框中呈现给用户的默认文件名。
filename*: «filename» 和 «filename*» 两个参数的唯一区别在于，»filename*»采用了 RFC 5987 中规定的编码方式。当»filename» 和 «filename*» 同时出现的时候，应该优先采用»filename*»，假如二者都支持的话。

HTTP 请求

起始行

HTTP请求是由客户端发出的消息，用来使服务器执行动作。起始行 (start-line) 包含三个元素：

一个 HTTP 方法，一个动词 (像 , 或者 ) 或者一个名词 (像或者 ), 描述要执行的动作. 例如, 表示要获取资源，表示向服务器推送数据 (创建或修改资源, 或者产生要返回的临时文件)。
请求目标 (request target)，通常是一个 URL，或者是协议、端口和域名的绝对路径，通常以请求的环境为特征。请求的格式因不同的 HTTP 方法而异。它可以是：
- 一个绝对路径，末尾跟上一个 ‘ ? ‘ 和查询字符串。这是最常见的形式，称为原始形式 (origin form)，被 GET，POST，HEAD 和 OPTIONS 方法所使用。
- 一个完整的URL，被称为绝对形式 (absolute form)，主要在使用方法连接到代理时使用。
- 由域名和可选端口（以为前缀）组成的 URL 的 authority component，称为 authority form。仅在使用建立 HTTP 隧道时才使用。
- 星号形式 (asterisk form)，一个简单的星号()，配合方法使用，代表整个服务器。
HTTP 版本 (HTTP version)，定义了剩余报文的结构，作为对期望的响应版本的指示符。

Headers

来自请求的 HTTP headers 遵循和 HTTP header 相同的基本结构：不区分大小写的字符串，紧跟着的冒号和一个结构取决于 header 的值。整个 header（包括值）由一行组成，这一行可以相当长。

有许多请求头可用，它们可以分为几组：

General headers，例如，适用于整个报文。
Entity headers，例如，适用于请求的 body。显然，如果请求中没有任何 body，则不会发送这样的头文件。

Body

请求的最后一部分是它的 body。不是所有的请求都有一个 body：例如获取资源的请求，GET，HEAD，DELETE 和 OPTIONS，通常它们不需要 body。有些请求将数据发送到服务器以便更新数据：常见的的情况是 POST 请求（包含 HTML 表单数据）。

Body 大致可分为两类：

Single-resource bodies，由一个单文件组成。该类型 body 由两个 header 定义：和 .
，由多部分 body 组成，每一部分包含不同的信息位。通常是和 HTML Forms 连系在一起。

Інформація про тіло повідомлення

indicates the size of the entity-body, in decimal number of octets, sent to the recipient.

Indicates the media type of the resource.

Used to specify the compression algorithm.

Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users’ own preferred language.

Indicates an alternate location for the returned data.

Проксі

Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.

Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.

Identifies the original host requested that a client used to connect to your proxy or load balancer.

identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.

Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.

Контекст запиту

Contains an Internet email address for a human user who controls the requesting user agent.

Вказує ім’я домену сервера (для віртуального хостингу) і (при необхідності) номер TCP-порту, на якому прослуховується сервер.

The address of the previous web page from which a link to the currently requested page was followed.

Контекст відповіді

Lists the set of HTTP request methods support by a resource.

Contains information about the software used by the origin server to handle the request.

Діапазон запитів

Indicates if the server supports range requests and if so, in which unit the range can be expressed.

Indicates the part of a document that the server should return.

Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.

Indicates where in a full body message a partial message belongs.

Безпека

Controls resources the user agent is allowed to load for a given page.

Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP request to the specified URI.

Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.

Force communication using HTTPS instead of HTTP.

Enables cross-site scripting filtering.

Кодування передачі

Specifies the the form of encoding used to safely transfer the entity to the user.

Specifies the transfer encodings the user agent is willing to accept.

Allows the sender to include additional fields at the end of chunked message.

Інше

Contains the date and time at which the message was originated.

Tells the browser that the page being loaded is going to want to perform a large allocation.

…

Indicates how long the user agent should wait before making a follow-up request.

Links generated code to a source map.

The relevant RFC document for the . The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Niether party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field .

Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.

Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.

…

Заголовки сущности

Заголовки сущности (англ. Entity Headers) — заголовки, сопровождающие каждую сущность как в запросах клиента, так и в ответах сервера. Тем не менее, наличие некоторых бессмыслено в заголовках запросов (например, Expires). В отдельный класс заголовки сущности выделены для того, чтобы не путать их с заголовками запроса или заголовками ответа при передаче (multipart/*). Заголовки запроса и ответа как и основные заголовки описывают всё сообщение в целом и размещаются только в начальном блоке заголовков, в то время как заголовки сущности характеризуют содержимое каждой части в отдельности располагаясь непосредственно перед её телом.

Content-Language

Указывает один или несколько естественных языков содержимого, для носителей которых оно предназначается.
Языки перечисляются через запятую, порядок значения не имеет.
Если данный заголовок опущен, то предполагается, что содержимое предназначено для людей, понимающих любой язык (или же язык вообще значения не имеет).
При этом возможно, что человек не отыщет там информацию на понятном ему языке.

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

В RFC сказано, что язык содержимого можно указывать для любых медиатипов, а не только для текста.
Например, если это видео, где люди говорят на английском, в котором сбоку расположено окошко с сурдопереводом на амслене, а внизу расположен перевод субтитрами на русском, то заголовок Content-Language должен иметь значение «».
При этом, если это видео, где герои говорят на японском, и присутствует голосовой перевод на русском, то следует указать только русский язык, так как японцам, скорее всего, будет трудно расслышать родную речь.

Заголовки HTTP¶

Заголовок HTTP (HTTP Header) — это строка в HTTP-сообщении, содержащая разделённую двоеточием пару вида «параметр-значение». Формат заголовка соответствует общему формату заголовков текстовых сетевых сообщений ARPA (RFC 822). Как правило, браузер и веб-сервер включают в сообщения более чем по одному заголовку. Заголовки должны отправляться раньше тела сообщения и отделяться от него хотя бы одной пустой строкой (CRLF).

Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). После названия сразу должен следовать символ двоеточия. Значение может содержать любые символы ASCII, кроме перевода строки (CR, код 10) и возврата каретки (LF, код 13).

Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов в названии и значении не имеет значения (если иное не предусмотрено форматом поля).

Пример заголовков ответа сервера:

Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 51
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

200 OK

Все HTTP-заголовки разделяются на четыре основных группы:

General Headers (Основные заголовки) — должны включаться в любое сообщение клиента и сервера.
Request Headers (Заголовки запроса) — используются только в запросах клиента.
Response Headers (Заголовки ответа) — присутствуют только в ответах сервера.
Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

Сущности (entity, в переводах также встречается название “объект”) — это полезная информация, передаваемая в запросе или ответе. Сущность состоит из метаинформации (заголовки) и непосредственно содержания (тело сообщения).

В отдельный класс заголовки сущности выделены, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (multipart/). Заголовки запроса и ответа, как и основные заголовки, описывают всё сообщение в целом и размещаются только в начальном блоке заголовков, в то время как заголовки сущности характеризуют содержимое каждой части в отдельности, располагаясь непосредственно перед её телом.

В таблице 3 приведено краткое описание некоторых HTTP-заголовков.

Таблица 3. Заголовки HTTP

В листинге 1 приведен фрагмент дампа заголовков при подключении к серверу http://example.org

Листинг 1. Заголовки HTTP

http://www.example.org/

GET http://www.example.org/ HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=.9,*/*;q=.8
Accept-Language: ru-ru,ru;q=.8,en-us;q=.5,en;q=.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=.7,*;q=.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 302 Moved Temporarily
Date: Thu, 03 Mar 2011 06:48:28 GMT
Location: http://www.iana.org/domains/example/
Server: BigIP
Content-Length: 
X-Cache: MISS from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive
----------------------------------------------------------
http://www.iana.org/domains/example/

GET http://www.iana.org/domains/example/ HTTP/1.1
Host: www.iana.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=.9,*/*;q=.8
Accept-Language: ru-ru,ru;q=.8,en-us;q=.5,en;q=.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=.7,*;q=.7
Keep-Alive: 115
Proxy-Connection: keep-alive

HTTP/1.0 200 OK
Server: Apache/2.2.3 (CentOS)
Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT
Content-Type: text/html; charset=UTF-8
Accept-Ranges: bytes
Date: Thu, 03 Mar 2011 04:04:36 GMT
Content-Length: 2945
Age: 9858
X-Cache: HIT from proxy.omgtu
Via: 1.0 proxy.omgtu (squid/3.1.8)
Connection: keep-alive

....

Інше

Contains the date and time at which the message was originated.

Tells the browser that the page being loaded is going to want to perform a large allocation.

…

Indicates how long the user agent should wait before making a follow-up request.

Links generated code to a source map.

Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.

…

Sessions

By default, every request HTTPie makes is completely independent of any
previous ones to the same host.

However, HTTPie also supports persistent
sessions via the option. In a session,
custom (except for the ones starting with or ),
, and
(manually specified or sent by the server) persist between requests
to the same host.

# Create a new session:
$ http --session=./session.json httpbin.org/headers API-Token:123

# Inspect / edit the generated session file:
$ cat session.json

# Re-use the existing session — the API-Token header will be set:
$ http --session=./session.json httpbin.org/headers

All session data, including credentials, cookie data,
and custom headers are stored in plain text.
That means session files can also be created and edited manually in a text
editor—they are regular JSON. It also means that they can be read by anyone
who has access to the session file.

Что такое код ответа сервера?

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

1xx — информационные:

100 — сервер принял первую часть запроса, можно подрожать передачу;
101 — нужно изменить протокол работы на более подходящий;
102 — на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх — операция успешна:

200 — запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
201 — после выполнения запроса был создан ресурс;
202 — запрос принят, но еще не обработан;
203 — запрос выполнен успешно, но информация для ответа взята из прокси;
204 — запрос обработан, но контента для отображения нет;
205 — попросить пользователя ввести необходимые данные;
206 — запрос обработан, но передана только часть контента;

3xx — перенаправления:

300 — есть несколько страниц для этого запроса, например, на нескольких языках;
301 — страница навсегда перемещена по новому адресу;
302 — документ был временно перемещен;
303 — документ необходимо загрузить по указанному адресу с помощью протокола GET;
304 — документ не изменился с последнего запроса;
305 — нужно использовать прокси;
307 — ресурс временно перемещен на новый адрес.

4хх — ошибка в запросе:

400 — неверный запрос;
401 — необходимо аутентифицироваться;
403 — запрос принят, но у вас нет доступа;
404 — страница не найдена на сервере;
405 — используемый метод нельзя применять на сервере;
408 — время ожидания передачи запроса истекло;
410 — ресурс полностью удален;
411 — нужно указать длину запроса;
413 — запрос слишком длинный;
414 — URI запроса слишком длинная.

5хх — ошибка сервера:

500 — внутренняя ошибка сервера;
501 — нужная функция не поддерживается;
502 — прокси не может соединиться со шлюзом;
503 — сервер не может обрабатывать запросы по техническим причинам;
504 — прокси не дождался ответа от сервера;
505 — версия протокола HTTP не поддерживается.