From 95aca4b4d8fa62815d4bd412fff1a364f842814a Mon Sep 17 00:00:00 2001 From: Ryan Johnson Date: Thu, 29 Apr 2021 16:16:42 -0700 Subject: remove retired locales (#699) --- files/uk/web/http/basics_of_http/index.html | 51 -- .../web/http/basics_of_http/mime_types/index.html | 367 -------------- files/uk/web/http/cors/index.html | 550 --------------------- .../uk/web/http/headers/accept-encoding/index.html | 110 ----- .../uk/web/http/headers/accept-language/index.html | 95 ---- files/uk/web/http/headers/connection/index.html | 47 -- .../uk/web/http/headers/content-length/index.html | 63 --- files/uk/web/http/headers/content-type/index.html | 114 ----- files/uk/web/http/headers/etag/index.html | 99 ---- files/uk/web/http/headers/if-match/index.html | 87 ---- files/uk/web/http/headers/index.html | 383 -------------- files/uk/web/http/headers/location/index.html | 79 --- files/uk/web/http/headers/referer/index.html | 81 --- files/uk/web/http/headers/user-agent/index.html | 134 ----- .../web/http/headers/x-forwarded-proto/index.html | 70 --- files/uk/web/http/index.html | 100 ---- files/uk/web/http/methods/get/index.html | 69 --- files/uk/web/http/methods/index.html | 75 --- files/uk/web/http/methods/post/index.html | 118 ----- files/uk/web/http/methods/put/index.html | 97 ---- files/uk/web/http/session/index.html | 171 ------- files/uk/web/http/status/100/index.html | 46 -- files/uk/web/http/status/101/index.html | 46 -- files/uk/web/http/status/200/index.html | 54 -- files/uk/web/http/status/201/index.html | 46 -- files/uk/web/http/status/203/index.html | 45 -- files/uk/web/http/status/204/index.html | 56 --- files/uk/web/http/status/206/index.html | 84 ---- files/uk/web/http/status/418/index.html | 39 -- files/uk/web/http/status/422/index.html | 41 -- files/uk/web/http/status/index.html | 171 ------- 31 files changed, 3588 deletions(-) delete mode 100644 files/uk/web/http/basics_of_http/index.html delete mode 100644 files/uk/web/http/basics_of_http/mime_types/index.html delete mode 100644 files/uk/web/http/cors/index.html delete mode 100644 files/uk/web/http/headers/accept-encoding/index.html delete mode 100644 files/uk/web/http/headers/accept-language/index.html delete mode 100644 files/uk/web/http/headers/connection/index.html delete mode 100644 files/uk/web/http/headers/content-length/index.html delete mode 100644 files/uk/web/http/headers/content-type/index.html delete mode 100644 files/uk/web/http/headers/etag/index.html delete mode 100644 files/uk/web/http/headers/if-match/index.html delete mode 100644 files/uk/web/http/headers/index.html delete mode 100644 files/uk/web/http/headers/location/index.html delete mode 100644 files/uk/web/http/headers/referer/index.html delete mode 100644 files/uk/web/http/headers/user-agent/index.html delete mode 100644 files/uk/web/http/headers/x-forwarded-proto/index.html delete mode 100644 files/uk/web/http/index.html delete mode 100644 files/uk/web/http/methods/get/index.html delete mode 100644 files/uk/web/http/methods/index.html delete mode 100644 files/uk/web/http/methods/post/index.html delete mode 100644 files/uk/web/http/methods/put/index.html delete mode 100644 files/uk/web/http/session/index.html delete mode 100644 files/uk/web/http/status/100/index.html delete mode 100644 files/uk/web/http/status/101/index.html delete mode 100644 files/uk/web/http/status/200/index.html delete mode 100644 files/uk/web/http/status/201/index.html delete mode 100644 files/uk/web/http/status/203/index.html delete mode 100644 files/uk/web/http/status/204/index.html delete mode 100644 files/uk/web/http/status/206/index.html delete mode 100644 files/uk/web/http/status/418/index.html delete mode 100644 files/uk/web/http/status/422/index.html delete mode 100644 files/uk/web/http/status/index.html (limited to 'files/uk/web/http') diff --git a/files/uk/web/http/basics_of_http/index.html b/files/uk/web/http/basics_of_http/index.html deleted file mode 100644 index 237dda5f72..0000000000 --- a/files/uk/web/http/basics_of_http/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Basics of HTTP -slug: Web/HTTP/Basics_of_HTTP -tags: - - Guide - - HTTP - - NeedsTranslation - - Overview - - TopicStub -translation_of: Web/HTTP/Basics_of_HTTP ---- -
{{HTTPSidebar}}
- -

HTTP is a pretty extensible protocol. It relies on a few basic concepts like the notion of resources and URIs, a simple structure of messages, and a client-server structure for the communication flow. On top of these basic concepts, numerous extensions have appeared over the years, adding new functionality and new semantics by creating new HTTP methods or headers.

- -

Articles

- -
-
Overview of HTTP
-
Describes what HTTP is and its role in the Web architecture, its position in the protocol stack.
-
Evolution of HTTP
-
HTTP was created in the early 1990s and has been extended several times. This article goes through its history and describes HTTP/0.9, HTTP/1.0, HTTP/1.1, and the modern HTTP/2 as well as minor novelties introduced over the years.
-
Negotiating an HTTP version
-
Explains how a client and a server can negotiate a specific HTTP version and eventually upgrade the protocol version used.
-
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.
-
Resource URLs {{Non-standard_Inline}}
-
Resource URLs, URLs prefixed with the resource: scheme, are used by Firefox and Firefox browser extensions to load resources internally, but some of the information is available to sites the browser connects to as well.
-
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/uk/web/http/basics_of_http/mime_types/index.html b/files/uk/web/http/basics_of_http/mime_types/index.html deleted file mode 100644 index daa5d20b23..0000000000 --- a/files/uk/web/http/basics_of_http/mime_types/index.html +++ /dev/null @@ -1,367 +0,0 @@ ---- -title: Типи MIME -slug: Web/HTTP/Basics_of_HTTP/MIME_types -translation_of: Web/HTTP/Basics_of_HTTP/MIME_types ---- -

A Multipurpose Internet Mail Extensions (MIME) type - тип багатоцільових розширень Інтернет-пошти - це стандарт, що вказує на характер і формат документа, файлу або набору байт. Означений і стандартизований в IETF RFC 6838.

- -

Internet Assigned Numbers Authority (IANA)  відповідає за всі офіційні типи MIME, і Ви можете знайти найновіший і повний список на сторінці Media Types.

- -
-

Браузери використовують тип MIME, а не розширення файлу, для означення того, як потрібно обробляти URL.  Тому дуже важливо, щоб сервери надсилали правильний тип MIME у заголовку відповіді {{HTTPHeader("Content-Type")}}.

-
- -

Синтаксис

- -

Загальна структура

- -
type/subtype
- -

Тип MIME складається з типу і підтипу - двох рядків, розділених /. Пробіли не дозволяються. Тип представляє категорію і може бути дискретним(discrete) або багаточастинним (multipart ). Підтип специфічний для кожного типу.

- -

Типи MIME нечутливі до регістру, але традиційно написані малими літерами.

- -

Дискретні (Discrete) типи

- -
text/plain
-text/html
-text/javascript
-text/css
-image/jpeg
-image/png
-audio/mpeg
-audio/ogg
-audio/*
-video/mp4
-application/*
-application/json
-application/ecmascript
-application/octet-stream
-…
- -

Дискретні типи позначають категорію документа. Вони можуть бути одним з наступних:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ТипОписПриклад типових підтипів
textБудь-який документ, що містить текст і теоретично читається людиноюtext/plain, text/html, text/css, text/javascript, text/markdown
imageБудь-яке зображення. Відео сюди не включено, хоча анімовані зображення (наприклад, анімовані GIF) описуються також типом image.image/gif, image/png, image/jpeg, image/bmp, image/webp, image/vnd.microsoft.icon
audioБудь-який аудіофайлaudio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoБудь-який відеофайлvideo/webm, video/ogg
applicationБудь-які двійкові дані, особливо дані, які будуть виконані або якось інтерпретовані.application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf
- -

Для текстових документів без особливого підтипу слід використовувати text/plain.

- -

Аналогічно, для двійкових документів без певного або відомого підтипу слід використовувати application/octet-stream.

- -

Багаточастинні типи

- -
multipart/form-data
-multipart/byteranges
- -

Багаточастинні (Multipart) типи позначають категорію документа, розбиту на частини, часто з різними типами MIME. Вони є складеними з частин документами. За винятком multipart/form-data, що використовуються в методі {{HTTPMethod("POST")}} HTML-форм і multipart/byteranges, що використовуються для надсилання документа з {{HTTPStatus("206")}} Partial Content, HTTP не обробляє багаточастинні документи спеціальним чином: повідомлення передається в браузер (який, ймовірно, покаже вікно "Зберегти як", якщо він не знає, як відобразити документ.)

- -

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

- -

application/octet-stream

- -

Типово, це бінарні файли. Оскільки це значить невідомий двійковий файл (unknown binary file), браузери зазвичай не виконують його, або запитують, чи він повинен бути виконаний. Вони розглядають його, аналогічно заголовку {{HTTPHeader("Content-Disposition")}} який встановлений в значення attachment, і пропонують діалогове вікно "Зберегти як".

- -

text/plain

- -

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

- -
-

Зверніть увагу, що text/plain не те саме що "один з текстових типів даних". Якщо браузер очікує конкретний тип текстових даних, то ймовірно, не вважатиме його відповідним до цього типу. Зокрема, якщо браузер завантажує text/plain файл з елемента {{HTMLElement("link")}}, який оголошує файли CSS, то не буде розпізнавати його як дійсні файли CSS, якщо ті будуть представлені як text/plain. Їх необхідно об'являти як MIME тип text/css.

-
- -

text/css

- -

Файли CSS, які використовуються для оформлення веб-сторінки, повинні бути надіслані з типом text/css. Якщо сервер не розпізнає суфікс .css для файлів CSS, він може надіслати їх за допомогою MIME типів text/plain або application/octet-stream. У ньому випадку більшість браузерів їх не розпізнають як CSS і будуть ігнорувати.

- -

text/html

- -

Весь HTML-вміст повинен подаватися з цим типом. На сьогодні, альтернативні типи MIME для XHTML (типу application/xhtml+xml) в основному безкорисні.

- -
-

Note: Примітка. Використовуйте типи application/xml або application/xhtml+xml, якщо ви хочете, щоб правила XML-парсингу були жорсткі, до розділів <![CDATA[…]]> та елементів не з HTML/SVG/MathML.

-
- -

text/javascript

- -

У розділі Мов сценаріїв у стандарті HTML зазначено:

- -
-

Сервери повинні використовувати text/javascript для ресурсів JavaScript. Сервери не повинні використовувати інші типи JavaScript MIME для ресурсів JavaScript і не повинні використовувати типи MIME, які не належать до JavaScript.

-
- -

Інші типи MIME JavaScript, які не слід використовувати, визначені в MIME Sniffing Standard наступним чином:

- - - -

Типи для зображень

- -

Лише декілька типів зображень є загальновизнаними, щоб бути безпечними для використання на веб-сторінці:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Тип MIMEТип зображення
image/gifзображення GIF (стискання без втрат, замінений на PNG)
image/jpegзображення JPEG
image/pngзображення PNG
image/svg+xmlзображення SVG (векторні зображення)
image/x-icon, image/vnd.microsoft.icon[1]піктограми Windows
- -

Існує дискусія щодо додавання до цього списку WebP (image/webp), але виробники веб-браузерів обережно приймають його.

- -

У веб-документах можна знайти інші види зображень. Наприклад, багато веб-браузерів підтримують зображення ICO для favicons, використовуючи MIME-тип image/x-icon  .

- -
-
Примітка 1
-
Незважаючи на те, що image/vnd.microsoft.icon зареєстровано в IANA, воно в основному не підтримується, а використовується image/x-icon .
-
- -

Аудіо- та відео-типи

- -

Як і зображення, HTML не означує підтримувані типи для елементів {{HTMLElement("audio")}} і {{HTMLElement("video")}} , тому лише деякі з них можуть використовуватися в Веб. Формати мультимедіа, що підтримуються аудіо- та відео-елементами HTML вказують як на застосовані кодеки, так і на контейнери, які можна для них використовувати.

- -

Тип аудіовізуальних файлів MIME в основному вказує на формати контейнерів. Найбільш поширеними для Веб є:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
тип MIMEтип Аудіо або відео
audio/wave
- audio/wav
- audio/x-wav
- audio/x-pn-wav		Аудіофайл у форматі контейнера WAVE. Часто підтримується аудіокодек PCM (кодек WAVE "1"), інші кодеки мають обмежену підтримку (якщо є).
audio/webmАудіофайл у форматі контейнера WebM. Найпоширенішими аудіокодеками є Vorbis і Opus.
video/webmВідеофайл, можливо з аудіо, у форматі контейнера WebM. VP8 і VP9 є найпоширенішими відеокодеками; Vorbis і Opus найбільш поширені аудіокодеки.
audio/oggАудіофайл у форматі контейнера OGG. Vorbis є найпоширенішим аудіокодеком, який використовується в такому контейнері.
video/oggВідеофайл, можливо, зі звуком, у форматі контейнера OGG. Зазвичай використовується в ньому відеокодек Theora, аудіокодек - Vorbis.
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
-(інші заголовки асоційовані з багаточастинним документом як цілим)
-
---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

- -

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

- -

Коли відправлено код статусу {{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

- -

Більшість веб-серверів надсилають нерозпізнані ресурси як MIME-тип application/octet-stream. З міркувань безпеки більшість браузерів не дозволяють встановлювати типові користувацькі дії для таких ресурсів, змушуючи користувача зберігати його на диску для подальшого використання.

- -

Деякі поширені неправильні конфігурації сервера:

- - - -

Авто-розпізнавання MIME (sniffing)

- -

За відсутності типу MIME, або в деяких випадках, коли браузери вважають, що вони неправильні, вони можуть виконувати авто-розпізнавання (MIME sniffing) - вгадуючи правильний тип MIME, переглядаючи байти ресурсу.

- -

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

- -

Інші способи передачі типу документів

- -

Типи MIME - не єдиний спосіб передати інформацію про тип документа:

- - - -

Див. також

- - - -
{{HTTPSidebar}}
diff --git a/files/uk/web/http/cors/index.html b/files/uk/web/http/cors/index.html deleted file mode 100644 index 80cb620485..0000000000 --- a/files/uk/web/http/cors/index.html +++ /dev/null @@ -1,550 +0,0 @@ ---- -title: Cross-Origin Resource Sharing (CORS) -slug: Web/HTTP/CORS -tags: - - AJAX - - CORS - - HTTP - - Безпека -translation_of: Web/HTTP/CORS ---- -
{{HTTPSidebar}}
- -

Cross-Origin Resource Sharing ({{Glossary("CORS")}}, перехресний обмін ресурсами) — це механізм, що за допомогою {{Glossary("HTTP")}}-заголовків дає {{Glossary("Browser", "переглядачеві")}} дозвіл завантажувати ресурси з певного джерела на запит web-застосунка, отриманого з відмінного джерела. Web-застосунок виконує перехресний HTTP-запит коли потребує ресурсів з джерела (домен, протокол чи порт), відмінного від його власного.

- -

Приклад перехресного запиту: JavaScript-код web-застосунка, розміщеного на http://domain-a.com, намагається за допомогою {{domxref("XMLHttpRequest", "AJAX")}}-запиту отримати http://api.domain-b.com/data.json.

- -

З міркувань безпеки, web-переглядачі припиняють всі перехресні HTTP-запити, здійснені кодом скриптів. Наприклад, XMLHttpRequest і Fetch API дотримуються правила одного джерела. Це означає, що web-застосунок, отриманий з певного джерела, не може виконувати запити до HTTP-ресурсів з відмінного джерела (хіба якщо відповідь, що з нього надходить, міститиме належні CORS-заголовки).

- -

Localized CORS request principle

- -

Механізм CORS уможливлює безпечні перехресні запити та передання даних між web-переглядачами та web-серверами. Сучасні web-переглядачі запроваджують підтримку CORS до API, як-от XMLHttpRequest або Fetch API, щоб зробити виконання перехресних HTTP-запитів якнайбезпечнішим.

- -

Для кого ця стаття?

- -

Для кожного, поза сумнівом.

- -

А саме для web-адміністраторів, а також розробників серверних та клієнських застосунків. Сучасні переглядачі запроваджують підтримку CORS з клієнтського боку (зокрема, обробку заголовків та обмеження неправомірних запитів), проте цей новий стандарт потребує, щоб сервер обробляв нові запити й додавав належні заголовки до відповідей. Докладніше про це оповідає стаття «перехресні запити з погляду сервера» для серверних розробників (зі зразками PHP-коду).

- -

До яких запитів стосується CORS?

- -

Цей стандарт покликаний дозволити міжсайтові HTTP-запити для:

- - - -

Ця стаття описує перехресний обмін ресурсами взагалі та окремі HTTP-заголовки, що для цього необхідні.

- -

Функціональний огляд

- -

Стандарт перехресного обміну ресурсами працює за допомогою додавання нових HTTP заголовків, що дозволять серверу описати набір витоків, які мають дозвіл на читання інформації використовуючи веб-браузер. На додаток, для HTTP методів запиту, що можуть спричини  побічний еффект на серверні дані (в особливості, для HTTP методів, окрім {{HTTPMethod("GET")}}, або для {{HTTPMethod("POST")}} використання із певним MIME types), специфікація передбачає, що браузерам "попередньо переглядають" запити, вимагають підтримуваних методів з сервера за допомогою HTTP {{HTTPMethod("OPTIONS")}} методів запиту, а потім після "схвалення" з сервера, надсилає фактичний запит методом фактичного запиту HTTP. Сервер також може повідомляти клієнтів чи "credentials" (включаючи Куки і HTTP Аутентифікаційні дані) повинні бути відправлені із запитом.

- -

У наступних розділах обговорюються сценарії, а також надається розбивка використовуваних заголовків HTTP.

- -

Приклади сценаріїв контролю доступу

- -

Тут ми представляємо три сценарії, які ілюструють, як працює перехресне походження ресурсів. У всіх цих прикладах використовується об’єкт {{domxref ("XMLHttpRequest")}}, який можна використовувати для виклику між сайтів у будь-якому підтримуваному браузері.

- -

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

- -

Обговорення міжпохідного обміну ресурсами з точки зору сервера (включаючи фрагменти коду PHP) можна знайти в статті управління доступом на стороні сервера (CORS).

- -

Прості запити

- -

Some requests don’t trigger a CORS preflight. Those are called “simple requests” in this article, though the {{SpecName('Fetch')}} spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:

- - - -
Note: 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.
- -
Note: WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari does not consider the request to meet the conditions for a “simple request”. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: 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, and Switch to a blacklist model for restricted Accept headers in simple CORS requests. No other browsers implement those extra restrictions, because they’re not part of the spec.
- -

For example, suppose web content on domain http://foo.example wishes to invoke content on domain http://bar.other. Code of this sort might be used within JavaScript deployed on foo.example:

- -
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();
-  }
-}
-
- -

This will lead to a simple exchange between the client and the server, using CORS headers to handle the privileges:

- -

- -

Let us look at what the browser will send to the server in this case, and let's see how the server responds:

- -
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]
-
- -

Lines 1 - 10 are headers sent. The main HTTP request header of note here is the {{HTTPHeader("Origin")}} header on line 10 above, which shows that the invocation is coming from content on the domain http://foo.example.

- -

Lines 13 - 22 show the HTTP response from the server on domain http://bar.other. In response, the server sends back an {{HTTPHeader("Access-Control-Allow-Origin")}} header, shown above in line 16. The use of the {{HTTPHeader("Origin")}} header and of {{HTTPHeader("Access-Control-Allow-Origin")}} show the access control protocol in its simplest use. In this case, the server responds with a Access-Control-Allow-Origin: * which means that the resource can be accessed by any domain in a cross-site manner. If the resource owners at http://bar.other wished to restrict access to the resource to requests only from http://foo.example, they would send back:

- -

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

- -

Note that now, no domain other than http://foo.example (identified by the ORIGIN: header in the request, as in line 10 above) can access the resource in a cross-site manner. The Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header.

- -

Preflighted requests

- -

Unlike “simple requests” (discussed above), "preflighted" requests first send an HTTP request by the {{HTTPMethod("OPTIONS")}} method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.

- -

In particular, a request is preflighted if any of the following conditions is true:

- - - -
Note: WebKit Nightly and Safari Technology Preview place additional restrictions on the values allowed in the {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, and {{HTTPHeader("Content-Language")}} headers. If any of those headers have ”non-standard” values, WebKit/Safari preflights the request. What WebKit/Safari considers “non-standard” values for those headers is not documented except in the following WebKit bugs: 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, and Switch to a blacklist model for restricted Accept headers in simple CORS requests. No other browsers implement those extra restrictions, because they’re not part of the spec.
- -

The following is an example of a request that will be preflighted.

- -
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);
-    }
-}
-
-......
-
- -

In the example above, line 3 creates an XML body to send with the POST request in line 8. Also, on line 9, a "customized" (non-standard) HTTP request header is set (X-PINGOTHER: pingpong). Such headers are not part of the HTTP/1.1 protocol, but are generally useful to web applications. Since the request uses a Content-Type of application/xml, and since a custom header is set, this request is preflighted.

- -

- -

(Note: as described below, the actual POST request does not include the Access-Control-Request-* headers; they are needed only for the OPTIONS request.)

- -

Let's take a look at the full exchange between client and server. The first exchange is the preflight request/response:

- -
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
-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
-
- -

Once the preflight request is complete, the real request is sent:

- -
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]
-
- -

Lines 1 - 12 above represent the preflight request with the {{HTTPMethod("OPTIONS")}} method. The browser determines that it needs to send this based on the request parameters that the JavaScript code snippet above was using, so that the server can respond whether it is acceptable to send the request with the actual request parameters. OPTIONS is an HTTP/1.1 method that is used to determine further information from servers, and is a {{Glossary("safe")}} method, meaning that it can't be used to change the resource. Note that along with the OPTIONS request, two other request headers are sent (lines 10 and 11 respectively):

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

The {{HTTPHeader("Access-Control-Request-Method")}} header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a POST request method. The {{HTTPHeader("Access-Control-Request-Headers")}} header notifies the server that when the actual request is sent, it will be sent with a X-PINGOTHER and Content-Type custom headers. The server now has an opportunity to determine whether it wishes to accept a request under these circumstances.

- -

Lines 14 - 26 above are the response that the server sends back indicating that the request method (POST) and request headers (X-PINGOTHER) are acceptable. In particular, let's look at lines 17-20:

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

The server responds with Access-Control-Allow-Methods and says that POST and GET are viable methods to query the resource in question. Note that this header is similar to the {{HTTPHeader("Allow")}} response header, but used strictly within the context of access control.

- -

The server also sends Access-Control-Allow-Headers with a value of "X-PINGOTHER, Content-Type", confirming that these are permitted headers to be used with the actual request. Like Access-Control-Allow-Methods, Access-Control-Allow-Headers is a comma separated list of acceptable headers.

- -

Finally, {{HTTPHeader("Access-Control-Max-Age")}} gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours. Note that each browser has a maximum internal value that takes precedence when the Access-Control-Max-Age is greater.

- -

Preflighted requests and redirects

- -

Most browsers currently don’t support following redirects for preflighted requests. If a redirect occurs for a preflighted request, most current browsers will report an error message such as the following.

- -
-

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

-
- -
-

Request requires preflight, which is disallowed to follow cross-origin redirect

-
- -

The CORS protocol originally required that behavior but was subsquently changed to no longer require it. However, most browsers have not yet implemented the change and still exhibit the behavior that was originally required.

- -

So until browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:

- - - -

But if it’s not possible to make those changes, then another way that may be possible is to this:

- -
    -
  1. Make a simple request (using Response.url for the Fetch API, or XHR.responseURL) to determine what URL the real preflighted request would end up at.
    2. -
  2. Make another request (the “real” request) using the URL you obtained from Response.url or XMLHttpRequest.responseURL in the first step.
    3. -
- -

However, if the request is one that triggers a preflight due to the presence of the `Authorization` header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.

- -

Requests with credentials

- -

The most interesting capability exposed by both {{domxref("XMLHttpRequest")}} or Fetch and CORS is the ability to make "credentialed" requests that are aware of HTTP cookies and HTTP Authentication information. By default, in cross-site {{domxref("XMLHttpRequest")}} or Fetch invocations, browsers will not send credentials. A specific flag has to be set on the {{domxref("XMLHttpRequest")}} object or the {{domxref("Request")}} constructor when it is invoked.

- -

In this example, content originally loaded from http://foo.example makes a simple GET request to a resource on http://bar.other which sets Cookies. Content on foo.example might contain JavaScript like this:

- -
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();
-  }
-}
- -

Line 7 shows the flag on {{domxref("XMLHttpRequest")}} that has to be set in order to make the invocation with Cookies, namely the withCredentials boolean value. By default, the invocation is made without Cookies. Since this is a simple GET request, it is not preflighted, but the browser will reject any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}: true header, and not make the response available to the invoking web content.

- -

- -

Here is a sample exchange between client and server:

- -
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]
-
- -

Although line 11 contains the Cookie destined for the content on http://bar.other, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (line 19) the response would be ignored and not made available to web content.

- -

Credentialed requests and wildcards

- -

When responding to a credentialed request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the "*" wildcard.

- -

Because the request headers in the above example include a Cookie header, the request would fail if the value of the Access-Control-Allow-Origin header were "*". But it does not fail: Because the value of the Access-Control-Allow-Origin header is "http://foo.example" (an actual origin) rather than the "*" wildcard, the credential-cognizant content is returned to the invoking web content.

- -

Note that the Set-Cookie response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.

- -

Third-party cookies

- -

Note that cookies set in CORS responses are subject to normal third-party cookie policies. In the example above, the page is loaded from foo.example, but the cookie on line 22 is sent by bar.other, and would thus not be saved if the user has configured their browser to reject all third-party cookies.

- -

The HTTP response headers

- -

This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.

- -

Access-Control-Allow-Origin

- -

A returned resource may have one {{HTTPHeader("Access-Control-Allow-Origin")}} header, with the following syntax:

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

The origin parameter specifies a URI that may access the resource. The browser must enforce this. For requests without credentials, the server may specify "*" as a wildcard, thereby allowing any origin to access the resource.

- -

For example, to allow http://mozilla.org to access the resource, you can specify:

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

If the server specifies an origin host rather than "*", then it could also include Origin in the Vary response header to indicate to clients that server responses will differ based on the value of the Origin request header.

- -

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/uk/web/http/headers/accept-encoding/index.html b/files/uk/web/http/headers/accept-encoding/index.html deleted file mode 100644 index a370ed187e..0000000000 --- a/files/uk/web/http/headers/accept-encoding/index.html +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Accept-Encoding -slug: Web/HTTP/Headers/Accept-Encoding -translation_of: Web/HTTP/Headers/Accept-Encoding -original_slug: Web/HTTP/Заголовки/Accept-Encoding ---- -
{{HTTPSidebar}}
- -

HTTP-заголовок запиту Accept-Encoding вказує, яке кодування контенту може зрозуміти клієнт. Зазвичай це вказує на алгоритм стиснення. Використовуючи узгодження вмісту, сервер вибирає одну з пропозицій, використовує її та інформує клієнта про вибір за допомогою заголовка відповіді {{HTTPHeader("Content-Encoding")}}.

- -

Навіть якщо клієнт і сервер підтримують однакові алгоритми стиснення, сервер може не стискати тіло відповіді, якщо значення identity також є прийнятним. Два загальні випадки призводять до цього:

- - - -

До тих пір, поки значення identity (тобто без кодування) явно не заборонено identity;q=0 або *;q=0 без іншого явно заданого значення для ідентифікації, сервер ніколи не повинен відправляти назад помилку {{HTTPStatus("406")}} Not Acceptable .

- -
Примітка: - - -
- - - - - - - - - - - - -
Тип заголовку{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}так
- -

Синтаксис

- -
Accept-Encoding: gzip
-Accept-Encoding: compress
-Accept-Encoding: deflate
-Accept-Encoding: br
-Accept-Encoding: identity
-Accept-Encoding: *
-
-// Multiple algorithms, weighted with the {{Glossary("Quality Values", "quality value")}} syntax:
-Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
- -

Директиви

- -
-
gzip
-
Формат стиснення, що використовує кодування Lempel-Ziv coding (LZ77), з 32-bit CRC.
-
compress
-
Формат стиснення, що використовує алгоритм Lempel-Ziv-Welch (LZW) .
-
deflate
-
Формат стиснення, що використовує структуру zlib, з алгоритмом стиснення deflate.
-
br
-
Формат стиснення, що використовує алгоритм Brotli .
-
identity
-
Позначає функцію ідентичності (тобто не стискати, не змінювати). Це значення завжди вважається прийнятним, навіть воно не вказане.
-
*
-
Відповідає будь-якому кодуванню вмісту, який ще не вказано в заголовку. Це значення є типовим, якщо заголовку немає. Це не значить, що будь-який алгоритм підтримується, просто не висловлюється жодних переваг.
-
;q= (qvalues weighting)
-
Будь-яке значення розміщується в порядку переваги, що виражається з використанням відносної величини якості, званої вагою.
-
- -

Приклади

- -
Accept-Encoding: gzip
-
-Accept-Encoding: gzip, compress, br
-
-Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
-
- -

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

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Accept-Encoding", "5.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
- -

Сумісність з браузерами

- - - -

{{Compat("http.headers.Accept-Encoding")}}

- -

Див. також

- - diff --git a/files/uk/web/http/headers/accept-language/index.html b/files/uk/web/http/headers/accept-language/index.html deleted file mode 100644 index 0f7aa943e1..0000000000 --- a/files/uk/web/http/headers/accept-language/index.html +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Accept-Language -slug: Web/HTTP/Headers/Accept-Language -translation_of: Web/HTTP/Headers/Accept-Language -original_slug: Web/HTTP/Заголовки/Accept-Language ---- -
{{HTTPSidebar}}
- -

Заголовок HTTP-запиту Accept-Language повідомляє про те, які мови клієнт може зрозуміти, і який варіант локалі є кращим. (За мовами ми маємо на увазі природні мови, такі як англійська, а не мови програмування.) Потім, використовуючи узгодження вмісту, сервер вибирає одну з пропозицій, використовує її та інформує клієнта про свій вибір за допомогою заголовку відповіді {{HTTPHeader("Content-Language")}}. Браузери встановлюють адекватні значення для цього заголовка відповідно до їхньої мови інтерфейсу користувача, і, навіть, якщо користувач може змінити її, це трапляється рідко (і не схвалюється, оскільки це призводить до fingerprinting).

- -

Цей заголовок є рекомендацією, яку слід використовувати, коли сервер не має можливості визначити мову іншим способом, наприклад, через конкретну URL-адресу, яка керується явним рішенням користувача. Рекомендується, щоб сервер ніколи не перевизначав явне рішення. Зміст Accept-Language часто не керується користувачем (як, наприклад, під час подорожі та використання Інтернет-кафе в іншій країні); користувач може також захотіти відвідати сторінку іншою мовою, ніж локалі свого інтерфейсу користувача.

- -

Якщо сервер не може обслуговувати будь-яку відповідну мову, він теоретично може відправити код помилки {{HTTPStatus("406")}} (Not Acceptable). Але, з кращого досвіду це робиться рідко, замість цього кращим способом є ігнорування у цьому випадку заголовка Accept-Language .

- - - - - - - - - - - - - - - - -
Тип заголовку{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}ні
{{Glossary("Simple header", "CORS-safelisted request-header")}}yes
- -

Синтаксис

- -
Accept-Language: <language>
-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>
-
-

Тег мови (який іноді називають "ідентифікатором локалі"). Він складається з тегу мови (2-3 літери), що представляє мову, за яким після символу  '-' можуть слідувати також додаткові літери підтегу. Найпоширенішою додатковою інформацією є варіант країни або регіону (наприклад, 'en-US' або 'fr-CA') або тип алфавіту (наприклад, 'sr-Latn'). Інші варіанти, такі як тип орфографії ('de-DE-1996'), зазвичай не використовуються в контексті цього заголовку.

-
-
*
-
Будь-яка мова; '*' використовується як шаблон заміни.
-
;q= (q-factor weighting)
-
Будь-яке значення, розміщене в порядку уподобань, виражене за допомогою відносного {{glossary("Quality values", "quality value")}} що називається вагою.
-
- -

Приклади

- -
Accept-Language: de
-
-Accept-Language: de-CH
-
-Accept-Language: en-US,en;q=0.5
-
- -

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

- - - - - - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Accept-Language", "5.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
BCP 47Tags for the Identification of Language
- -

Сумісність з браузерами

- - - -

{{Compat("http.headers.Accept-Language")}}

- -

Див. також

- - diff --git a/files/uk/web/http/headers/connection/index.html b/files/uk/web/http/headers/connection/index.html deleted file mode 100644 index 9a103cd159..0000000000 --- a/files/uk/web/http/headers/connection/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Connection -slug: Web/HTTP/Headers/Connection -translation_of: Web/HTTP/Headers/Connection -original_slug: Web/HTTP/Заголовки/Connection ---- -
{{HTTPSidebar}}
- -

Загальний заголовок Connection означує, чи залишається мережне з'єднання відкритим після завершення поточної транзакції. Якщо надіслане значення зберігається, зв'язок постійний і не закривається, що дозволяє виконувати наступні запити на один і той же сервер.

- -
Поля заголовка, специфічні для підключення, такі як Connection, не повинні використовуватися у версіях HTTP починаючи з 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")}}, але це не є обов'язковим).  y).

- - - - - - - - - - - - -
Header type{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}yes
- -

Синтаксис

- -
Connection: keep-alive
-Connection: close
-
- -

Директиви

- -
-
close
-
Вказує, що клієнт або сервер хотіли б закрити з'єднання. Це типово, для запитів HTTP/1.0.
-
будь які розділені комою заголовки HTTP [як правило тільки keep-alive]
-
Вказує, що клієнт хоче, щоб з'єднання було відкрито. Постійне підключення - це типово для запитів HTTP/1.1. Список заголовків - це ім'я заголовка, який буде видалено першим непрозорим проксі-сервером або кешем між ними: ці заголовки визначають зв'язок між передавачем і першим об'єктом, а не кінцевим вузлом.
-
- -

Сумісність з браузерами

- - - -

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

diff --git a/files/uk/web/http/headers/content-length/index.html b/files/uk/web/http/headers/content-length/index.html deleted file mode 100644 index 335c8c1525..0000000000 --- a/files/uk/web/http/headers/content-length/index.html +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Content-Length -slug: Web/HTTP/Headers/Content-Length -translation_of: Web/HTTP/Headers/Content-Length -original_slug: Web/HTTP/Заголовки/Content-Length ---- -
{{HTTPSidebar}}
- -

Заголовок об'єкта Content-Length вказує розмір в байтах корисного навантаження, надісланих одержувачу.

- - - - - - - - - - - - -
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}yes
- -

Синтаксис

- -
Content-Length: <length>
-
- -

Директиви

- -
-
<length>
-
Довжина в кількостях октетів, вказана в десятковій формі.
-
- -

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

- - - - - - - - - - - - - - -
SpecificationTitle
{{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/uk/web/http/headers/content-type/index.html b/files/uk/web/http/headers/content-type/index.html deleted file mode 100644 index a01da3a2d6..0000000000 --- a/files/uk/web/http/headers/content-type/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Content-Type -slug: Web/HTTP/Headers/Content-Type -translation_of: Web/HTTP/Headers/Content-Type -original_slug: Web/HTTP/Заголовки/Content-Type ---- -
{{HTTPSidebar}}
- -

Заголовок об'єкта Content-Type використовується для позначення ресурсу {{Glossary("MIME type","media type")}} .

- -

У відповідях у заголовку Content-Type сервер повідомляє клієнту, який саме тип вмісту повертається. Браузери в деяких випадках виконують стеження за MIME і не обов'язково слідкують за значенням цього заголовка; Щоб запобігти такій поведінці, заголовок {{HTTPHeader("X-Content-Type-Options")}} може бути встановлений рівним nosniff.

- -

У запитах (наприклад, {{HTTPMethod("POST")}} або {{HTTPMethod("PUT")}}) клієнт повідомляє серверу, який тип даних відправляється.

- - - - - - - - - - - - - - - - -
Header type{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
- -

Синтаксис

- -
Content-Type: text/html; charset=utf-8
-Content-Type: multipart/form-data; boundary=something
-
- -

Директиви

- -
-
media-type
-
Тип MIME ресурсу або даних.
-
charset
-
Стандарт кодування символів.
-
boundary
-
Для багаточастинних (multipart) об'єктів необхідна директива boundary , яка складається з 1 до 70 символів з набору символів, відомих як дуже надійні через шлюзи електронної пошти, і не закінчуючись пробілами. Директива використовується для інкапсуляції меж кількох частин повідомлення. Часто кордон заголовка доповнюється двома тире в тілі, і кінцева межа також має два тире, які додаються.
-
- -

Приклади

- -

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"
-
-якийсь текст
------------------------------974767299852498929531610575
-Content-Disposition: form-data; name="myFile"; filename="foo.txt"
-Content-Type: text/plain
-
-(вміст вивантажуваного файлу foo.txt)
------------------------------974767299852498929531610575--
-
- -

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

- - - - - - - - - - - - - - - - - - -
SpecificationTitle
{{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/uk/web/http/headers/etag/index.html b/files/uk/web/http/headers/etag/index.html deleted file mode 100644 index fcbd7a8ed6..0000000000 --- a/files/uk/web/http/headers/etag/index.html +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: ETag -slug: Web/HTTP/Headers/ETag -translation_of: Web/HTTP/Headers/ETag -original_slug: Web/HTTP/Заголовки/ETag ---- -
{{HTTPSidebar}}
- -

ETag HTTP заголовок відповіді. Є ідентифікатором для поточної версії ресурсу. Він надає можливість створювати кеш більш ефективно, і запобігає перенапругам у системі, створюючи доступність простору інтернету. Щойно надійде відповідь що данні не змінювались, то нема потреби знову це завантажувати. 

- -

Якщо дані з цього URL змінились, ETag код має бути змінений.  Отже Etags створюються для ідентифікації і відстежування ресурсів інтернету. Порівняння кожного з них надає можливість відстежувати які дані змінились і мають бути перезавантажені.

- - - - - - - - - - - - -
Тип заголовку{{Glossary("Заголовок відповіді")}}
{{Glossary("Прихований  заголовок")}}Ні
- -

Синтаксис

- -
ETag: W/"<etag_value>"
-ETag: "<etag_value>"
-
- -

Вказники

- -
-
W/ {{optional_inline}}
-
'W/' (чутливо до регістру) вказує виконати детальну перевірку. Детальна перевірка допустима, але рідше використовуєтся для порівняння. Строга валідація ідеально підходіть для порівняння, але має дуже складний алгорітм і шкодить ефективності. Для підвищення ефективності використовуються Etag значення двох копій одне й те самого ресурсу. Порівняння коротких фраз кодів, ніж порівнювати кожен байт файлу, є ефективна ідея.
-
"<etag_value>"
-
Унікальний хеш код ресурсу. Це звичайні набір символів ASCII у подвійних лапках (приклад "675af34563dc-tr34"). В звичайному випадку це хеш дати останньої модіфікаії, або це может бути будь який код. Наприклад, MDN викорустовує хеш шістнадцятирічних символів контенту вікіпедії.
-
- -

Приклади

- -
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
-ETag: W/"0815"
- -

Виникаючі повітряні колізії

- -

За допомогою ETag і з заголовком {{HTTPHeader("If-Match")}}, можливо натрапити на повітряні колізії.

- -

Наприклад, коли редагується MDN, поточний вікі контент захешований у Etag і доданий до відповіді:

- -
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
- -

{{HTTPMethod("POST")}} запит у вікі сторінках (додання даних/зміни) матиме {{HTTPHeader("If-Match")}} заголовок із ETag кодом, для перевірки актуальності даних.

- -
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
- -

Якщо хеш не сходиться, це означає що данні змінилися, документ був змінений нещодавно і {{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, без тіла відповіді, то поточна версія є актуальна(fresh).

- -

Стандарти

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7232", "ETag", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Сумісність с оглядачами

- - - -

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

- -

See also

- - diff --git a/files/uk/web/http/headers/if-match/index.html b/files/uk/web/http/headers/if-match/index.html deleted file mode 100644 index 03fba37b45..0000000000 --- a/files/uk/web/http/headers/if-match/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: If-Match -slug: Web/HTTP/Headers/If-Match -translation_of: Web/HTTP/Headers/If-Match -original_slug: Web/HTTP/Заголовки/If-Match ---- -
{{HTTPSidebar}}
- -

If-Match HTTP заголовок запиту робить запит умовним. Для {{HTTPMethod("GET")}} і {{HTTPMethod("HEAD")}} методів, сервер поверне запитаний ресурс тільки якщо співпадає обидва ETags. Для методу {{HTTPMethod("PUT")}} чи інших небезпечних методів, виконається тільки завантаження файлу.

- -

Порівняння коду {{HTTPHeader("ETag")}} може використовувати суворий алгоритм порівняння, мається на увазі повна перевірка байт в байт. Ця функція використовує  W/ префікс на початку ETag.

- -

Існує два загальних випадки використання: 

- - - - - - - - - - - - - - -
Тип заголовку{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}Ні
- -

Синтаксис

- -
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: *
-
- -

Стандарт

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7232", "If-Match", "3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Сумісність з оглядачами

- - - -

{{Compat("http.headers.If-Match")}}

- -

Дивись також

- - diff --git a/files/uk/web/http/headers/index.html b/files/uk/web/http/headers/index.html deleted file mode 100644 index e1bdee7d50..0000000000 --- a/files/uk/web/http/headers/index.html +++ /dev/null @@ -1,383 +0,0 @@ ---- -title: HTTP заголовки -slug: Web/HTTP/Headers -translation_of: Web/HTTP/Headers -original_slug: Web/HTTP/Заголовки ---- -
{{HTTPSidebar}}
- -

Заголовки HTTP дозволяють клієнту та серверу передавати додаткову інформацію у запиті чи відповіді. Заголовок запиту складається з нечутливих до регістру імен, за якими йде двокрапка ':', а потім їх значення (без розбиття на рядки). Пробіли перед значеннями ігноруються.

- -

Користувальницькі значення заголовків можуть бути додані за допомогою префіксу 'X-' . Однак ця домовленість більше не підтримується з червня 2012, через незручність, яку вона викликала, коли нестандартизовані поля стали стандартними у RFC 6648; інші значення  перераховані у IANA registry, оригінальний зміст якого був виначений у RFC 4229. IANA також підтримує реєстр запропонованих нових значень заголовків повідомлення HTTP.

- -

Заголовки можуть бути сгруповані, відповідно до їхнього змісту:

- - - -

Заголовки також можуть бути згруповані за тим, як проксі обробляє їх:

- -
-
End-to-end (точка-точка або наскрізні) заголовки
-
Ці заголовки повинні бути передані кінцевому отримувачу повідомлення; серверу, що оброблює запит, або клієнту, який отримує відповідь. Проміжний проксі має повторно передати наскрізні заголовки незмінніми, а кеш повинен зберегти їх.
-
Hop-by-hop (крок-за-кроком або проміжні) заголовки
-
Ці заголовки мають значення лише для одного з'єднання транспортного рівня та не повинні бути повторно передані через проксі або кеш. Це такі заголовки, як: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} та {{ httpheader("Upgrade") }}. Зазначте, що лише проміжні заголовки можуть бути встановлені за допомогою загального заголовку {{ httpheader("Connection") }}.
-
- -

Наступний лист підсумовує заголовки HTTP по категорії їхнього використання. Список за абеткою дивись у навігаційному листі зліва.

- -

Аутентифікація

- -
-
{{HTTPHeader("WWW-Authenticate")}}
-
Визначають методи аутентифікації, що мають бути використані для отримання доступу до ресурсу.
-
{{HTTPHeader("Authorization")}}
-
Містить облікові данні для аутентифікації агента користувача сервером.
-
{{HTTPHeader("Proxy-Authenticate")}}
-
Визначає метод аутентифікації, який має бути використаний для отримання доступу до ресурсу через проксі сервер.
-
{{HTTPHeader("Proxy-Authorization")}}
-
Містить облікові данні для аутентифікації агента користувача проксі сервером.
-
- -

Кешування

- -
-
{{HTTPHeader("Age")}}
-
Час у секундах, який об'єкт має бути у кеші проксі.
-
{{HTTPHeader("Cache-Control")}}
-
Означує директиви механізму кешування як у запиті, так і у відповіді.
-
{{HTTPHeader("Expires")}}
-
Дата/час, після якої відповідь вважається застарілою.
-
{{HTTPHeader("Pragma")}}
-
Залежний від реалізації заголовок, який може викликати декілька ефектів де завгодно у ланцюгу запит-відповідь. Використвується для зворотної сумісності з кешем HTTP/1.0, де заголовок Cache-Control ще не присутній.
-
{{HTTPHeader("Warning")}}
-
Загальне попереджувальне поле, яке містить інформацію про імовірні проблеми.
-
- -

Клієнтські підказки

- -
-
-

HTTP Client hints are a work in progress. Actual documentation can be found on the website of the HTTP working group.

-
-
{{HTTPHeader("Accept-CH")}} {{experimental_inline}}
-
Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute ([HTML5]).
-
{{HTTPHeader("Content-DPR")}} {{experimental_inline}}
-
The “Content-DPR” response header field is a number that indicates the ratio between physical pixels over CSS px of the selected image response.
-
{{HTTPHeader("DPR")}} {{experimental_inline}}
-
The “DPR” request header field is a number that indicates the client’s current Device Pixel Ratio (DPR), which is the ratio of physical pixels over CSS px (Section 5.2 of [CSSVAL]) of the layout viewport (Section 9.1.1 of [CSS2]) on the device.
-
{{HTTPHeader("Save-Data")}} {{experimental_inline}}
-
The SaveData [CLIENT-HINTS] request header field consists of one or more tokens that indicate user agent's preference for reduced data usage
-
{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}
-
-
-

The “Viewport-Width” request header field is a number that indicates the layout viewport width in CSS px. The provided CSS px value is a number rounded to the smallest following integer (i.e. ceiling value).

-
- -
-

If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.

-
-
-
{{HTTPHeader("Width")}} {{experimental_inline}}
-
-
-

The “Width” request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image). The provided physical px value is a number rounded to the smallest following integer (i.e. ceiling value).

-
- -
-

If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field can be omitted. If Width occurs in a message more than once, the last value overrides all previous occurrences

-
-
-
{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}
-
Servers can ask the client to remember the set of Client Hints that the server supports for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server’s origin ([RFC6454]).
-
{{HTTPHeader("Early-Data")}} {{experimental_inline}}
-
Indicates that the request has been conveyed in early data.
-
- -
-
-

Умови

-
-
{{HTTPHeader("Last-Modified")}}
-
It is a validator, the last modification date of the resource, used to compare several versions of the same resource. It is less accurate than {{HTTPHeader("ETag")}}, but easier to calculate in some environments. Conditional requests using {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Unmodified-Since")}} use this value to change the behavior of the request.
-
{{HTTPHeader("ETag")}}
-
It is a validator, a unique string identifying the version of the resource. Conditional requests using {{HTTPHeader("If-Match")}} and {{HTTPHeader("If-None-Match")}} use this value to change the behavior of the request.
-
{{HTTPHeader("If-Match")}}
-
Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.
-
{{HTTPHeader("If-None-Match")}}
-
Makes the request conditional and applies the method only if the stored resource doesn't match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one is already existing.
-
{{HTTPHeader("If-Modified-Since")}}
-
Makes the request conditional and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.
-
{{HTTPHeader("If-Unmodified-Since")}}
-
Makes the request conditional and expects the entity to be transmitted only if it has not been modified after the given date. This is used to ensure the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.
-
- -

Управління з'єднанням

- -
-
{{HTTPHeader("Connection")}}
-
Вказує чи повинно мережне з'єднання залишатися відкритим після завершення поточної транзакції.
-
{{HTTPHeader("Keep-Alive")}}
-
Controls how long a persistent connection should stay open.
-
- -

Узгодження змісту

- -
-
{{HTTPHeader("Accept")}}
-
Informs the server about the types of data that can be sent back. It is MIME-type.
-
{{HTTPHeader("Accept-Charset")}}
-
Informs the server about which character set the client is able to understand.
-
{{HTTPHeader("Accept-Encoding")}}
-
Інформує сервер про алгоритм кодування, зазвичай алгоритм стиснення, який може бути використаний на ресурсі, відправленому назад.
-
{{HTTPHeader("Accept-Language")}}
-
Інформує сервер про мову, на яку сервер очікує відправлення. Це рекомендація і не обов'язково знаходиться під повним контролем користувача: сервер завжди повинен звертати увагу, щоб не перевизначити явний вибір користувача (наприклад, вибір мови у випадаючому списку).
-
- -
-
- -

Контроль

- -
-
{{HTTPHeader("Expect")}}
-
Indicates expectations that need to be fulfilled by the server in order to properly handle the request.
-
{{HTTPHeader("Max-Forwards")}}
-
...
-
- -

Cookies

- -
-
{{HTTPHeader("Cookie")}}
-
Contains stored HTTP cookies previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.
-
{{HTTPHeader("Set-Cookie")}}
-
Send cookies from the server to the user agent.
-
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
-
Used to contain an HTTP cookie, previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been obsoleted by the specification. Use {{HTTPHeader("Cookie")}} instead.
-
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
-
Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.
-
-

CORS

-
-
{{HTTPHeader("Access-Control-Allow-Origin")}}
-
Indicates whether the response can be shared.
-
{{HTTPHeader("Access-Control-Allow-Credentials")}}
-
Indicates whether the response to the request can be exposed when the credentials flag is true.
-
{{HTTPHeader("Access-Control-Allow-Headers")}}
-
Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
-
{{HTTPHeader("Access-Control-Allow-Methods")}}
-
Specifies the method or methods allowed when accessing the resource in response to a preflight request.
-
{{HTTPHeader("Access-Control-Expose-Headers")}}
-
Indicates which headers can be exposed as part of the response by listing their names.
-
{{HTTPHeader("Access-Control-Max-Age")}}
-
Indicates how long the results of a preflight request can be cached.
-
{{HTTPHeader("Access-Control-Request-Headers")}}
-
Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.
-
{{HTTPHeader("Access-Control-Request-Method")}}
-
Used when issuing a preflight request to let the server know which HTTP method will be used when the actual request is made.
-
{{HTTPHeader("Origin")}}
-
Indicates where a fetch originates from.
-
- -

Не відстежується

- -
-
{{HTTPHeader("DNT")}}
-
Used for expressing the user's tracking preference.
-
{{HTTPHeader("Tk")}}
-
Indicates the tracking status that applied to the corresponding request.
-
- -

Завантаження

- -
-
{{HTTPHeader("Content-Disposition")}}
-
Is a response header if the resource transmitted should be displayed inline (default behavior when the header is not present), or it should be handled like a download and the browser should present a 'Save As' window.
-
- -

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

- -
-
{{HTTPHeader("Content-Length")}}
-
indicates the size of the entity-body, in decimal number of octets, sent to the recipient.
-
{{HTTPHeader("Content-Type")}}
-
Indicates the media type of the resource.
-
{{HTTPHeader("Content-Encoding")}}
-
Used to specify the compression algorithm.
-
{{HTTPHeader("Content-Language")}}
-
Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
-
{{HTTPHeader("Content-Location")}}
-
Indicates an alternate location for the returned data.
-
-

Проксі

-
-
- -
-
{{HTTPHeader("Forwarded")}}
-
Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.
-
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
-
Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.
-
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
-
Identifies the original host requested that a client used to connect to your proxy or load balancer.
-
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
-
identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.
-
{{HTTPHeader("Via")}}
-
Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.
-
- -

Перенаправлення

- -
-
{{HTTPHeader("Location")}}
-
Позначає URL-адресу сторінки для перенаправлення.
-
- -

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

- -
-
{{HTTPHeader("From")}}
-
Contains an Internet email address for a human user who controls the requesting user agent.
-
{{HTTPHeader("Host")}}
-
Вказує ім'я домену сервера (для віртуального хостингу) і (при необхідності) номер TCP-порту, на якому прослуховується сервер.
-
{{HTTPHeader("Referer")}}
-
The address of the previous web page from which a link to the currently requested page was followed.
-
{{HTTPHeader("Referrer-Policy")}}
-
Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.
-
{{HTTPHeader("User-Agent")}}
-
Містить характеристичний рядок, що дозволяє одноранговим мережним протоколам ідентифікувати тип програми, операційну систему, постачальника програмного забезпечення або версію програмного забезпечення користувача, що запитує програмне забезпечення. Див. Також посилання на рядок користувача агента Firefox. посилання на рядок користувача Firefox.
-
- -

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

- -
-
{{HTTPHeader("Allow")}}
-
Lists the set of HTTP request methods support by a resource.
-
{{HTTPHeader("Server")}}
-
Contains information about the software used by the origin server to handle the request.
-
- -

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

- -
-
{{HTTPHeader("Accept-Ranges")}}
-
Indicates if the server supports range requests and if so, in which unit the range can be expressed.
-
{{HTTPHeader("Range")}}
-
Indicates the part of a document that the server should return.
-
{{HTTPHeader("If-Range")}}
-
Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.
-
{{HTTPHeader("Content-Range")}}
-
Indicates where in a full body message a partial message belongs.
-
- -

Безпека

- -
-
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
-
Controls resources the user agent is allowed to load for a given page.
-
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
-
Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP POST request to the specified URI.
-
{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})
-
Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.
-
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
-
Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.
-
- -
-
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
-
Force communication using HTTPS instead of HTTP.
-
{{HTTPHeader("Upgrade-Insecure-Requests")}}
-
Надсилає на сервер сигнал, який вказує на бажання клієнта на зашифровану і аутентифіковану відповідь, і що він може успішно обробити директиву {{CSP("upgrade-insecure-requests")}} 
-
- -
-
{{HTTPHeader("X-Content-Type-Options")}}
-
Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.
-
- -
-
{{HTTPHeader("X-Frame-Options")}} (XFO)
-
Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}
-
{{HTTPHeader("X-XSS-Protection")}}
-
Enables cross-site scripting filtering.
-
- -

Події надіслані сервером

- -
-
{{HTTPHeader("Ping-From")}}
-
...
-
{{HTTPHeader("Ping-To")}}
-
...
-
{{HTTPHeader("Last-Event-ID")}}
-
...
-
- -

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

- -
-
{{HTTPHeader("Transfer-Encoding")}}
-
Specifies the the form of encoding used to safely transfer the entity to the user.
-
{{HTTPHeader("TE")}}
-
Specifies the transfer encodings the user agent is willing to accept.
-
{{HTTPHeader("Trailer")}}
-
Allows the sender to include additional fields at the end of chunked message.
-
- -

WebSockets

- -
-
{{HTTPHeader("Sec-WebSocket-Key")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Extensions")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Accept")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Protocol")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Version")}}
-
...
-
- -

Інше

- -
-
{{HTTPHeader("Date")}}
-
Contains the date and time at which the message was originated.
-
{{HTTPHeader("Large-Allocation")}}
-
Tells the browser that the page being loaded is going to want to perform a large allocation.
-
{{HTTPHeader("Link")}}
-
...
-
{{HTTPHeader("Retry-After")}}
-
Indicates how long the user agent should wait before making a follow-up request.
-
{{HTTPHeader("SourceMap")}}
-
Links generated code to a source map.
-
{{HTTPHeader("Upgrade")}}
-
The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7.  The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection.  For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field.  Niether party is required to accept the terms specified in the Upgrade header field.  It can be used in both client and server headers.  If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified.  For details on the Connection header field please see section 6.1 of the aforementioned RFC.
-
{{HTTPHeader("Vary")}}
-
Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.
-
{{HTTPHeader("X-DNS-Prefetch-Control")}}
-
Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
-
{{HTTPHeader("X-Firefox-Spdy")}}
-
...
-
{{HTTPHeader("X-Requested-With")}}
-
...
-
{{HTTPHeader("X-UA-Compatible")}}
-
...
-
- -

Внесок

- -

Ви можете допомогти, написав нові записи або покращити існуючі.

- -

Дивись також

- - diff --git a/files/uk/web/http/headers/location/index.html b/files/uk/web/http/headers/location/index.html deleted file mode 100644 index c982e45bc2..0000000000 --- a/files/uk/web/http/headers/location/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Location -slug: Web/HTTP/Headers/Location -translation_of: Web/HTTP/Headers/Location -original_slug: Web/HTTP/Заголовки/Location ---- -
{{HTTPSidebar}}
- -

Заголовок відповіді Location вказує URL-адресу для перенаправлення сторінки. Він надає лише значення, коли подається відповідь зі статусом 3xx (перенаправлення) або 201 (створений).

- -

У випадках перенаправлення, метод HTTP, який використовується для внесення нового запиту на вибір сторінки, на яку позначається Location, залежить від оригінального методу та виду перенаправлення:

- - - -

Усі відповіді з одним із цих кодів стану надсилають заголовок Location .

- -

У випадках створення ресурсу, сервер вказує URL-адресу новоствореного ресурсу.

- -

Location та {{HTTPHeader ("Content-Location")}} є різними: Location вказує на ціль перенаправлення (або URL новоствореного ресурсу), тоді як {{HTTPHeader ("Content-Location")}} вказує на пряму URL-адресу, яка використовується для доступу до ресурсу, коли відбувається узгодження вмісту, без необхідності подальшого узгодження вмісту. Location є заголовком, пов'язаним з відповіддю, тоді як {{HTTPHeader ("Content-Location")}} асоціюється з повернутим об'єктом.

- - - - - - - - - - - - -
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
- -

Синтаксис

- -
Location: <url>
-
- -

Директиви

- -
-
<url>
-
Відносна (до URL-адреси запиту) або абсолютна URL-адреса.
-
- -

Приклади

- -
Location: /index.html
- -

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

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Location", "7.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Сумісність з браузерами

- - - -

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

- -

See also

- - diff --git a/files/uk/web/http/headers/referer/index.html b/files/uk/web/http/headers/referer/index.html deleted file mode 100644 index b51eb309e2..0000000000 --- a/files/uk/web/http/headers/referer/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Referer -slug: Web/HTTP/Headers/Referer -translation_of: Web/HTTP/Headers/Referer -original_slug: Web/HTTP/Заголовки/Referer ---- -
{{HTTPSidebar}}
- -

Заголовок запиту Referer містить адресу попередньої веб-сторінки, з якої було отримано посилання на поточну запитувану сторінку. Заголовок Referer дозволяє серверам визначати, звідки люди відвідують їх, і можуть використовувати ці дані для аналітики, ведення журналів або оптимізованого кешування, наприклад.

- -

Зауважте, що написання referer є помилкою слову "referrer". Дивіться {{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}} більш детальніше.

- -
-

Заголовок Referer потенційно має можливість для виявлення інформації про історію перегляду  браузера користувача, що є конфіденційним.

-
- -

Заголовок Referer не надсилається браузерами, якщо:

- - - - - - - - - - - - - - -
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}Так
- -

Синтаксис

- -
Referer: <url>
-
- -

Директиви

- -
-
<url>
-
Абсолютна або часткова адреса попередньої веб-сторінки, з якої було зроблено посилання на поточну запитувана сторінку. URL фрагменти (i.e. "#section") та інформація про користувача (i.e. "username:password" в "https://username:password@example.com/foo/bar/") не входять.
-
- -

Приклади

- -
Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript
- -

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

- - - - - - - - - - - - -
СпецифікаціяНазва
{{RFC("7231", "Referer", "5.5.2")}}Протокол передачі гіпертексту (HTTP/1.1): Семантика та зміст
- -

Сумісність браузера

- - - -

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

- -

Дивіться також

- - diff --git a/files/uk/web/http/headers/user-agent/index.html b/files/uk/web/http/headers/user-agent/index.html deleted file mode 100644 index b0d7c5ce67..0000000000 --- a/files/uk/web/http/headers/user-agent/index.html +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: User-Agent -slug: Web/HTTP/Headers/User-Agent -translation_of: Web/HTTP/Headers/User-Agent -original_slug: Web/HTTP/Заголовки/User-Agent ---- -
{{HTTPSidebar}}
- -

Заголовок запиту User-Agent містить характерний рядок, який дозволяє однорідним мережевим протоколам ідентифікувати тип програми, операційну систему, постачальника програмного забезпечення або версію програмного забезпечення запитуючого користувацького агента програмного забезпечення.

- -
-

Будь ласка, прочитайте Виявлення браузера за допомогою агента користувача і чому обслуговування різних веб-сторінок або служб для різних браузерів зазвичай погана ідея.

-
- - - - - - - - - - - - -
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
- -

Синтаксис

- -
User-Agent: <product> / <product-version> <comment>
-
-Common format for web browsers:
-
-User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>
-
- -

Директиви

- -
-
<product>
-
A product identifier
-
<product-version>
-
A version number of the product.
-
<comment>
-
Zero or more comments containing sub product information, for example.
-
- -

Firefox UA string

- -

For more details on Firefox and Gecko based user agent strings, see the Firefox user agent string reference. The UA string of Firefox itself is broken down into four components:

- -

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion

- - - -

Examples

- -
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
-Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
-
- -

Chrome UA string

- -

The Chrome (or Chromium/blink-based engines) user agent string is similar to the Firefox format. For compatibility, it adds strings like "KHTML, like Gecko" and "Safari".

- -

Examples

- -
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
- -

Opera UA string

- -

The Opera browser is also based on the blink engine, which is why it almost looks the same, but adds "OPR/<version>".

- -

Examples

- -
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
- -

Safari UA string

- -

In this example, the user agent string is mobile safari version. It contains the word "Mobile".

- -

Examples

- -
Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1
- -

Internet Explorer UA string

- -

Examples

- -
Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
- -

Crawler and bot UA strings

- -

Examples

- -
Googlebot/2.1 (+http://www.google.com/bot.html)
- -

Specifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "User-Agent", "5.5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Browser compatibility

- - - -

{{Compat("http.headers.User-Agent")}}

- -

See also

- - diff --git a/files/uk/web/http/headers/x-forwarded-proto/index.html b/files/uk/web/http/headers/x-forwarded-proto/index.html deleted file mode 100644 index 45dd2ed485..0000000000 --- a/files/uk/web/http/headers/x-forwarded-proto/index.html +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: X-Forwarded-Proto -slug: Web/HTTP/Headers/X-Forwarded-Proto -translation_of: Web/HTTP/Headers/X-Forwarded-Proto -original_slug: Web/HTTP/Заголовки/X-Forwarded-Proto ---- -
{{HTTPSidebar}}
- -

X-Forwarded-Proto (XFP) - це HTTP заголовок, який де-факто використовується використув для ідентифікації протоколу (HTTP or HTTPS) який використовує клієнт, для підключення через проксі або до лоад балансера.

- -

Логи доступу до сервера включають протокол, що використовується між сервером та лоад балансером, але не включають той, за допомогою якого клієнт підключається до лоад балансера. Для того щоб передати інформацію про протокол з'єднання між клієнтом та лоад балансером на сервер, потрібно додати до запиту заголовок X-Forwarded-Proto.

- -

Стандартизованою версією цього заголовка являється - HTTP {{HTTPHeader("Forwarded")}} заголовок.

- - - - - - - - - - - - -
Тип заголовка{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}no
- -

Синтаксис

- -
X-Forwarded-Proto: <protocol>
-
- -

Директиви

- -
-
<protocol>
-
Протокол, що переадресовуюється (http або https).
-
- -

Приклади

- -
X-Forwarded-Proto: https
- -

Інші не стандартні форми використання:

- -
# Microsoft
-Front-End-Https: on
-
-X-Forwarded-Protocol: https
-X-Forwarded-Ssl: on
-X-Url-Scheme: https
-
- -

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

- -

Не являється частиною поточної специфікації. Стандартизована версія йього заголовку - {{HTTPHeader("Forwarded")}}.

- -

Сумісність з браузерами

- - - -

{{Compat("http.headers.X-Forwarded-Proto")}}

- -

Дивіться також

- - diff --git a/files/uk/web/http/index.html b/files/uk/web/http/index.html deleted file mode 100644 index eb38dd6d92..0000000000 --- a/files/uk/web/http/index.html +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: HTTP -slug: Web/HTTP -tags: - - HTTP - - NeedsTranslation - - Reference - - TopicStub - - Web - - 'l10n:priority' -translation_of: Web/HTTP ---- -
{{HTTPSidebar}}
- -

Протокол передачі гіпертексту (Hypertext Transfer Protocol - HTTP) це прикладний протокол для передачі гіпертекстових документів, таких як HTML. Він був розроблений для зв'язку між веб-браузерами та веб серверами, проте може використовуватись і для інших цілей. HTTP дотримується класичної моделі клієнт-сервер, коли клієнт відкриває з'єднання для здійснення запиту, а потім чекає поки отримає відповідь. HTTP - це протокол без збереження стану, що означає, що сервер не зберігає жодних даних (стану) між двома запитами. Хоча часто він базується на стеку протоколів TCP/IP, він може використовувати будь-який надійний протокол транспортного рівня, тобто протокол, який не втрачає "мовчки" повідомлення, як це робить UDP. RUDP - надійне оновлення UDP - є підходящою альтернативою.

- -
-
-

Посібники

- -

Дізнайтеся, як використовувати HTTP завдяки підручникам та посібникам.

- -
-
Overview of HTTP
-
The basic features of the client-server protocol: what it can do and its intended uses.
-
HTTP Cache
-
Caching is very important for fast Web sites. This article describes different methods of caching and how to use HTTP Headers to control them.
-
HTTP Cookies
-
How cookies work is defined by RFC 6265. When serving an HTTP request, a server can send a Set-Cookie HTTP header with the response. The client then returns the cookie's value with every request to the same server in the form of a Cookie request header. The cookie can also be set to expire on a certain date, or restricted to a specific domain and path.
-
HTTP Access Control (CORS)
-
Cross-site HTTP requests are HTTP requests for resources from a different domain than the domain of the resource making the request. For instance, an HTML page from Domain A (http://domaina.example/) makes a request for an image on Domain B (http://domainb.foo/image.jpg) via the img element. Web pages today very commonly load cross-site resources, including CSS stylesheets, images, scripts, and other resources. CORS allows web developers to control how their site reacts to cross-site requests.
-
- -
-
Evolution of HTTP
-
A brief description of the changes between the early versions of HTTP, to the modern HTTP/2 and beyond.
-
Mozilla web security guidelines
-
A collection of tips to help operational teams with creating secure web applications.
-
- -
-
HTTP Messages
-
Describes the type and structure of the different kind of messages of HTTP/1.x and HTTP/2.
-
A typical HTTP session
-
Shows and explains the flow of a usual HTTP session.
-
Connection management in HTTP/1.x
-
Describes the three connection management models available in HTTP/1.x, their strengths, and their weaknesses.
-
-
- -
-

Довідники

- -

Перегляньте детальну довідкову документацію HTTP.

- -
-
HTTP Headers
-
HTTP message headers are used to describe a resource, or the behavior of the server or the client. Custom proprietary headers can be added using the X- prefix; others in an IANA registry, whose original content was defined in RFC 4229. IANA also maintains a registry of proposed new HTTP message headers.
-
HTTP Request Methods
-
The different operations that can be done with HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, and also less common requests like {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, or {{HTTPMethod("TRACE")}}.
-
HTTP Status Response Codes
-
HTTP response codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirections, client errors, and servers errors.
-
CSP directives
-
The {{HTTPHeader("Content-Security-Policy")}} response header fields allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.
-
- -

Інструменти і ресурси

- -

Helpful tools and resources for understanding and debugging HTTP.

- -
-
Firefox Developer Tools
-
Network monitor
-
Mozilla Observatory
-
-

A project designed to help developers, system administrators, and security professionals configure their sites safely and securely.

-
-
RedBot
-
Tools to check your cache-related headers
-
How Browsers Work
-
A very comprehensive article on browser internals and request flow through HTTP protocol. A MUST-READ for any web developer.
-
-
-
- -
- -
-
-
-
- -
- -
-
- -
-
-
diff --git a/files/uk/web/http/methods/get/index.html b/files/uk/web/http/methods/get/index.html deleted file mode 100644 index cb677dc943..0000000000 --- a/files/uk/web/http/methods/get/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: GET -slug: Web/HTTP/Methods/GET -translation_of: Web/HTTP/Methods/GET ---- -
{{HTTPSidebar}}
- -

HTTP-метод GET запитує представлення зазначеного ресурсу. Запити, які використовують GET, повинні лише отримувати дані.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Запит має тілоНі
Успішна відповідь має тілоТак
{{Glossary("Safe")}}Так
{{Glossary("Idempotent")}}Так
{{Glossary("Cacheable")}}Так
Дозволений в HTML-формахТак
- -

Синтаксис

- -
GET /index.html
-
- -

Приклад

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Сумісність з браузерами

- - - -

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

- -

Див. також

- - diff --git a/files/uk/web/http/methods/index.html b/files/uk/web/http/methods/index.html deleted file mode 100644 index f70eecf38f..0000000000 --- a/files/uk/web/http/methods/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: HTTP-методи запиту -slug: Web/HTTP/Methods -tags: - - HTTP - - Methods - - NeedsTranslation - - Reference - - TopicStub -translation_of: Web/HTTP/Methods ---- -
{{HTTPSidebar}}
- -

Щоб вказати потрібну дію, яку необхідно зробити з ресурсом, в HTTP означено набір методів запиту (request methods). Ці методи іноді називають HTTP-дієсловами, незважаючи на те, що вони можуть бути іменниками. Кожен з них реалізує іншу семантику, але вони мають деякі спільні риси, за якими їх поділяють на групи: наприклад методи запиту можуть бути {{glossary("safe")}}, {{glossary("idempotent")}}, або {{glossary("cacheable")}}.

- -
-
GET
-
Метод GET запитує представлення вказаного ресурсу. Запити, які використовують GET, повинні лише отримувати дані.
-
HEAD
-
Метод HEAD запитує відповідь, ідентичну запиту GET, але без тіла.
-
POST
-
Метод POST використовується для відправки об'єкта на вказаний ресурс, часто викликаючи зміну стану або побічних ефектів на сервері
-
PUT
-
-

Метод PUT замінює всі поточні представлення цільового ресурсу на корисне навантаження, що вказане в запиті.

-
-
DELETE
-
Метод DELETE видаляє вказаний ресурс.
-
CONNECT
-
-

Метод CONNECT встановлює тунель до сервера, ідентифікованого цільовим ресурсом.

-
-
OPTIONS
-
Метод OPTIONS використовується для опису варіантів зв'язку до цільового ресурсу.
-
TRACE
-
-

Метод TRACE виконує тест зворотного зв'язку по шляху до цільового ресурсу.

-
-
PATCH
-
Метод PATCH використовується для застосування часткових модифікацій в ресурсі.
-
- -

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

- - - - - - - - - - - - - - - - - - - -
SpecificationTitleComment
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentSpecifies GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH Method for HTTPSpecifies PATCH.
- -

Сумісність з браузерами

- - - -

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

- -

Дивіться також

- - diff --git a/files/uk/web/http/methods/post/index.html b/files/uk/web/http/methods/post/index.html deleted file mode 100644 index 8ab0ccf386..0000000000 --- a/files/uk/web/http/methods/post/index.html +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: POST -slug: Web/HTTP/Methods/POST -translation_of: Web/HTTP/Methods/POST ---- -
{{HTTPSidebar}}
- -

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

- -

Різниця між PUT і {{HTTPMethod("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:

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

Форма, що використовує тип вмісту multipart/form-data:

- -
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
- -

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

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Сумісність з браузерами

- - - -

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

- -

See also

- - diff --git a/files/uk/web/http/methods/put/index.html b/files/uk/web/http/methods/put/index.html deleted file mode 100644 index c66918862e..0000000000 --- a/files/uk/web/http/methods/put/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: PUT -slug: Web/HTTP/Methods/PUT -translation_of: Web/HTTP/Methods/PUT ---- -
Метод 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/uk/web/http/session/index.html b/files/uk/web/http/session/index.html deleted file mode 100644 index 96e10d914a..0000000000 --- a/files/uk/web/http/session/index.html +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: A typical HTTP session -slug: Web/HTTP/Session -translation_of: Web/HTTP/Session ---- -
{{HTTPSidebar}}
- -

В клієнт-серверних протоколах таких як  HTTP, сесії складаються з трьох фаз:

- -
    -
  1. Клієнт встановлює TCP з'єднання  (або підходяще з'єднання якщо неможливо зробити це на TCP).
    2. -
  2. Клієнт посилає запит , і очікує відповіді .
    3. -
  3. Сервер обробляє запит , І посилає відповідь , надаючи код статусу  і відповідні дані
    4. -
- -

Починаючи з версії HTTP/1.1, з'єднання більше не  закривається після завершення третьої фази, і клієнту тепер надається можливість подальшого запиту: це означає, що друга та третя фази  можуть тепер виконуватись будь-яку кількість разів.

- -

Встановлення з'єданння 

- -

В клієнт-серверних протоколах , клієнт встановлює з'єднання. Відкриття з'єднання в HTTP Означає втановлення з'єднанняна транспортному рівні , зазвичай використовується TCP.

- -

З TCP порт за замовчуванням, для HTTP сервера на будь-якому комп'ютері становить порт 80. Інші порти також можуть бути використані, як наприклад 8000 чи 8080. Для запиту сторінки URL повинен включати в себе домене ім'я та номер порту, але порт можна опустити якщо його номер 80. Дивись Identifying resources on the Web для детальної інформації.

- -
Note: The client-server model does not allow the server to send data to the client without an explicit request for it. To work around this problem, web developers use several techniques: ping the server periodically via the {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} APIs, using the WebSockets API, or similar protocols.
- -

Надсилання клієнтського запиту 

- -

Once the connection is established, the user-agent can send the request (a user-agent is typically a web browser, but can be anything else, a crawler, for example). A client request consists of text directives, separated by CRLF (carriage return, followed by line feed), divided into three blocks:

- -
    -
  1. The first line contains a request method followed by its parameters: -
      -
    • the path of the document, i.e. an absolute URL without the protocol or domain name
      • -
    • the HTTP protocol version
      • -
    -
    2. -
  2. Subsequent lines represent an HTTP header, giving the server information about what type of data is appropriate (e.g., what language, what MIME types), or other data altering its behavior (e.g., not sending an answer if it is already cached). These HTTP headers form a block which ends with an empty line.
    3. -
  3. The final block is an optional data block, which may contain further data mainly used by the POST method.
    4. -
- -

Приклади запитів 

- -

Fetching the root page of developer.mozilla.org, i.e. http://developer.mozilla.org/, and telling the server that the user-agent would prefer the page in French, if possible:

- -
GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
-
- -

Observe that final empty line, this separates the data block from the header block. As there is no Content-Length provided in an HTTP header, this data block is presented empty, marking the end of the headers, allowing the server to process the request the moment it receives this empty line.

- -

For example, sending the result of a form:

- -
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 defines a set of request methods indicating the desired action to be performed upon a resource. Although they can also be nouns, these requests methods are sometimes referred as HTTP verbs. The most common requests are GET and POST:

- - - -

Структура  відповіді сервера 

- -

After the connected agent has sent its request, the web server processes it, and ultimately returns a response. Similar to a client request, a server response is formed of text directives, separated by CRLF, though divided into three blocks:

- -
    -
  1. The first line, the status line, consists of an acknowledgment of the HTTP version used, followed by a status request (and its brief meaning in human-readable text).
    2. -
  2. Subsequent lines represent specific HTTP headers, giving the client information about the data sent (e.g. type, data size, compression algorithm used, hints about caching). Similarly to the block of HTTP headers for a client request, these HTTP headers form a block ending with an empty line.
    3. -
  3. The final block is a data block, which contains the optional data.
    4. -
- -

Приклади відповідей

- -

Успішна відповідь :

- -
HTTP/1.1 200 OK
-Content-Type: text/html; charset=utf-8
-Content-Length: 55743
-Connection: keep-alive
-Cache-Control: s-maxage=300, public, max-age=0
-Content-Language: en-US
-Date: Thu, 06 Dec 2018 17:37:18 GMT
-ETag: "2e77ad1dc6ab0b53a2996dfd4653c1c3"
-Server: meinheld/0.6.1
-Strict-Transport-Security: max-age=63072000
-X-Content-Type-Options: nosniff
-X-Frame-Options: DENY
-X-XSS-Protection: 1; mode=block
-Vary: Accept-Encoding,Cookie
-Age: 7
-
-
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="utf-8">
-  <title>A simple webpage</title>
-</head>
-<body>
-  <h1>Simple HTML5 webpage</h1>
-  <p>Hello, world!</p>
-</body>
-</html>
-
- -

Notification that the requested resource has permanently moved:

- -
HTTP/1.1 301 Moved Permanently
-Server: Apache/2.4.37 (Red Hat)
-Content-Type: text/html; charset=utf-8
-Date: Thu, 06 Dec 2018 17:33:08 GMT
-Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it)
-Keep-Alive: timeout=15, max=98
-Accept-Ranges: bytes
-Via: Moz-Cache-zlb05
-Connection: Keep-Alive
-Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link)
-
-
-<!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
-
- -

Notification that the requested resource doesn't exist:

- -
HTTP/1.1 404 Not Found
-Content-Type: text/html; charset=utf-8
-Content-Length: 38217
-Connection: keep-alive
-Cache-Control: no-cache, no-store, must-revalidate, max-age=0
-Content-Language: en-US
-Date: Thu, 06 Dec 2018 17:35:13 GMT
-Expires: Thu, 06 Dec 2018 17:35:13 GMT
-Server: meinheld/0.6.1
-Strict-Transport-Security: max-age=63072000
-X-Content-Type-Options: nosniff
-X-Frame-Options: DENY
-X-XSS-Protection: 1; mode=block
-Vary: Accept-Encoding,Cookie
-X-Cache: Error from cloudfront
-
-
-<!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
-
- -

Статус коди відповідей

- -

HTTP response status codes indicate if a specific HTTP request has been successfully completed. Responses are grouped into five classes: informational responses, successful responses, redirects, client errors, and servers errors.

- - - -

See also

- - diff --git a/files/uk/web/http/status/100/index.html b/files/uk/web/http/status/100/index.html deleted file mode 100644 index 60b1d9d609..0000000000 --- a/files/uk/web/http/status/100/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 100 Продовження -slug: Web/HTTP/Status/100 -tags: - - 100 Continue - - 100 Продовжити - - HTTP -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/uk/web/http/status/101/index.html b/files/uk/web/http/status/101/index.html deleted file mode 100644 index 4248f1cdff..0000000000 --- a/files/uk/web/http/status/101/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 101 Зміна протоколів -slug: Web/HTTP/Status/101 -translation_of: Web/HTTP/Status/101 ---- -
{{HTTPSidebar}}
- -

Код відповіді HTTP 101 Switching Protocols вказує на протокол, на який сервер перемикається за запитом клієнта, який надіслав повідомлення, включаючий заголовок запиту {{HTTPHeader ("Upgrade")}}.

- -

Сервер включає в цю відповідь заголовок відповіді {{HTTPHeader ("Upgrade")}} і вказує протокол, на який він перейшов. Процес детально описаний у статті Протокол механізму оновлення.

- -

Статус

- -
101 Switching Protocols
- -

Приклади

- -

Зміна протоколів може використовуватись з 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/uk/web/http/status/200/index.html b/files/uk/web/http/status/200/index.html deleted file mode 100644 index 90157eba33..0000000000 --- a/files/uk/web/http/status/200/index.html +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: 200 OK -slug: Web/HTTP/Status/200 -tags: - - 200 OK - - HTTP - - HTTP Статус -translation_of: Web/HTTP/Status/200 ---- -
{{HTTPSidebar}}
- -

Код відповіді на статус успіху 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/uk/web/http/status/201/index.html b/files/uk/web/http/status/201/index.html deleted file mode 100644 index aa8c04df08..0000000000 --- a/files/uk/web/http/status/201/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 201 Створений -slug: Web/HTTP/Status/201 -tags: - - 201 Created - - 201 Створено - - HTTP - - HTTP Статус -translation_of: Web/HTTP/Status/201 ---- -
{{HTTPSidebar}}
- -

Код відповіді HTTP 201 Created  вказує на те, що запит був успішним і призвів до створення ресурсу. Новий ресурс ефективно створюється до відправки цієї відповіді і повертається в тілі повідомлення, його місце розташування - це URL-адреса запиту або вміст заголовка {{HTTPHeader ("Location")}}.

- -

Загальний випадок коду цього стану є результатом запиту {{HTTPMethod ("PUT")}}.

- -

Статус

- -
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/uk/web/http/status/203/index.html b/files/uk/web/http/status/203/index.html deleted file mode 100644 index c1cfddde79..0000000000 --- a/files/uk/web/http/status/203/index.html +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 203 Non-Authoritative Information -slug: Web/HTTP/Status/203 -tags: - - HTTP - - Довідка - - Успішна відповідь - - код стану - - код стану HTTP -translation_of: Web/HTTP/Status/203 ---- -
{{HTTPSidebar}}
- -

Стан відповіді HTTP 203 Non-Authoritative Information (укр. Не авторитетна інформація) вказує на те, що запит був успішним, але додане корисне навантаження було змінено через {{Glossary("Proxy server", "проксі")}} трансформації, з відповіді {{HTTPStatus("200")}} (OK) сервера-джерела.

- -

Відповідь 203 схожа на значення 214, що означає Transformation Applied (укр. Застосовується трансформація) коду заголовка {{HTTPHeader("Warning")}}, що має додаткову перевагу при застосуванні до відповідей з будь-яким кодом стану (анг. status code).

- -

Стан

- -
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/uk/web/http/status/204/index.html b/files/uk/web/http/status/204/index.html deleted file mode 100644 index 5762dec47a..0000000000 --- a/files/uk/web/http/status/204/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: 204 Без вмісту -slug: Web/HTTP/Status/204 -tags: - - '204' - - 204 No Content - - 204 Без вмісту - - HTTP -translation_of: Web/HTTP/Status/204 ---- -
{{HTTPSidebar}}
- -

Код відповіді 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")}}

- -

Compatibility notes

- - - -

Дивись також

- - diff --git a/files/uk/web/http/status/206/index.html b/files/uk/web/http/status/206/index.html deleted file mode 100644 index 9c4da2ba75..0000000000 --- a/files/uk/web/http/status/206/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: 206 Частковий вміст -slug: Web/HTTP/Status/206 -tags: - - 206 Частковий зміст - - HTTP - - HTTP Статус - - Запити діапазону -translation_of: Web/HTTP/Status/206 ---- -
{{HTTPSidebar}}
- -

Код статусу 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--
- -

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

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7233", "206 Partial Content" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- -

Сумісність з браузерами

- - - -

{{Compat("http.status.206")}}

- -

Дивись також

- - diff --git a/files/uk/web/http/status/418/index.html b/files/uk/web/http/status/418/index.html deleted file mode 100644 index 176fa6f000..0000000000 --- a/files/uk/web/http/status/418/index.html +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: 418 I'm a teapot -slug: Web/HTTP/Status/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
- -

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

- - - - - - - - - - - - -
СпецифікаціяНазва
{{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/uk/web/http/status/422/index.html b/files/uk/web/http/status/422/index.html deleted file mode 100644 index be92381f02..0000000000 --- a/files/uk/web/http/status/422/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 422 Unprocessable Entity -slug: Web/HTTP/Status/422 -tags: - - HTTP - - HTTP Status Code - - WebDAV - - Довідка - - Клієнтська помилка - - Код відповіді - - Помилка клієнта -translation_of: Web/HTTP/Status/422 ---- -

{{HTTPSidebar}}

- -

Код відповіді HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity означає, що сервер розуміє тип сутності запиту, і синтаксис цієї сутності вірний, проте опрацювати вміщені в неї інструкції неможливо.

- -
-

Важливо: клієнт не повинен повторювати цей запит без його модифікації.

-
- -

Статус

- -
422 Unprocessable Entity
- -

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

- - - - - - - - - - - - - - -
СпецифікаціїНазва
{{RFC("4918", "422 Unprocessable Entity" , "11.2")}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
diff --git a/files/uk/web/http/status/index.html b/files/uk/web/http/status/index.html deleted file mode 100644 index e490502369..0000000000 --- a/files/uk/web/http/status/index.html +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: HTTP response status codes -slug: Web/HTTP/Status -tags: - - HTTP - - NeedsTranslation - - Status codes - - TopicStub -translation_of: Web/HTTP/Status ---- -
{{HTTPSidebar}}
- -

HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirects, client errors, and servers errors. Status codes are defined by section 10 of RFC 2616.

- -

Information responses

- -
-
{{HTTPStatus(100, "100 Continue")}}
-
This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.
-
{{HTTPStatus(101, "101 Switching Protocol")}}
-
This code is sent in response to an {{HTTPHeader("Upgrade")}} request header by the client, and indicates the protocol the server is switching too.
-
{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})
-
This code indicates that the server has received and is processing the request, but no response is available yet.
-
- -

Successful responses

- -
-
{{HTTPStatus(200, "200 OK")}}
-
The request has succeeded. The meaning of a success varies depending on the HTTP method:
- GET: The resource has been fetched and is transmitted in the message body.
- HEAD: The entity headers are in the message body.
- POST: The resource describing the result of the action is transmitted in the message body.
- TRACE: The message body contains the request message as received by the server
-
{{HTTPStatus(201, "201 Created")}}
-
The request has succeeded and a new resource has been created as a result of it. This is typically the response sent after a PUT request.
-
{{HTTPStatus(202, "202 Accepted")}}
-
The request has been received but not yet acted upon. It is non-committal, meaning that there is no way in HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.
-
{{HTTPStatus(203, "203 Non-Authoritative Information")}}
-
This response code means returned meta-information set is not exact set as available from the origin server, but collected from a local or a third party copy. Except this condition, 200 OK response should be preferred instead of this response.
-
{{HTTPStatus(204, "204 No Content")}}
-
There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones.
-
{{HTTPStatus(205, "205 Reset Content")}}
-
This response code is sent after accomplishing request to tell user agent reset document view which sent this request.
-
{{HTTPStatus(206, "206 Partial Content")}}
-
This response code is used because of range header sent by the client to separate download into multiple streams.
-
{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})
-
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.
-
{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})
-
Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.
-
{{HTTPStatus(226, "226 IM Used")}} (HTTP Delta encoding)
-
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
-
- -

Redirection messages

- -
-
{{HTTPStatus(300, "300 Multiple Choice")}}
-
The request has more than one possible responses. User-agent or user should choose one of them. There is no standardized way to choose one of the responses.
-
{{HTTPStatus(301, "301 Moved Permanently")}}
-
This response code means that URI of requested resource has been changed. Probably, new URI would be given in the response.
-
{{HTTPStatus(302, "302 Found")}}
-
This response code means that URI of requested resource has been changed temporarily. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.
-
{{HTTPStatus(303, "303 See Other")}}
-
Server sent this response to directing client to get requested resource to another URI with an GET request.
-
{{HTTPStatus(304, "304 Not Modified")}}
-
This is used for caching purposes. It is telling to client that response has not been modified. So, client can continue to use same cached version of response.
-
305 Use Proxy {{deprecated_inline}}
-
Was defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy. It has been deprecated due to security concerns regarding in-band configuration of a proxy.
-
306 unused
-
This response code is no longer used, it is just reserved currently. It was used in a previous version of the HTTP 1.1 specification.
-
{{HTTPStatus(307, "307 Temporary Redirect")}}
-
Server sent this response to directing client to get requested resource to another URI with same method that used prior request. This has the same semantic than the 302 Found HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
-
{{HTTPStatus(308, "308 Permanent Redirect")}}
-
This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.
-
- -

Client error responses

- -
-
{{HTTPStatus(400, "400 Bad Request")}}
-
This response means that server could not understand the request due to invalid syntax.
-
{{HTTPStatus(401, "401 Unauthorized")}}
-
Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.
-
402 Payment Required
-
This response code is reserved for future use. Initial aim for creating this code was using it for digital payment systems however this is not used currently.
-
{{HTTPStatus(403, "403 Forbidden")}}
-
The client does not have access rights to the content, i.e. they are unauthorized, so server is rejecting to give proper response. Unlike 401, the client's identity is known to the server.
-
{{HTTPStatus(404, "404 Not Found")}}
-
The server can not find requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. This response code is probably the most famous one due to its frequent occurence on the web.
-
{{HTTPStatus(405, "405 Method Not Allowed")}}
-
The request method is known by the server but has been disabled and cannot be used. For example, an API may forbid DELETE-ing a resource. The two mandatory methods, GET and HEAD, must never be disabled and should not return this error code.
-
{{HTTPStatus(406, "406 Not Acceptable")}}
-
This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content following the criteria given by the user agent.
-
{{HTTPStatus(407, "407 Proxy Authentication Required")}}
-
This is similar to 401 but authentication is needed to be done by a proxy.
-
{{HTTPStatus(408, "408 Request Timeout")}}
-
This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message.
-
{{HTTPStatus(409, "409 Conflict")}}
-
This response is sent when a request conflicts with the current state of the server.
-
{{HTTPStatus(410, "410 Gone")}}
-
This response would be sent when the requested content has been permenantly deleted from server, with no forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification intends this status code to be used for "limited-time, promotional services". APIs should not feel compelled to indicate resources that have been deleted with this status code.
-
{{HTTPStatus(411, "411 Length Required")}}
-
Server rejected the request because the Content-Length header field is not defined and the server requires it.
-
{{HTTPStatus(412, "412 Precondition Failed")}}
-
The client has indicated preconditions in its headers which the server does not meet.
-
{{HTTPStatus(413, "413 Payload Too Large")}}
-
Request entity is larger than limits defined by server; the server might close the connection or return an Retry-After header field.
-
{{HTTPStatus(414, "414 URI Too Long")}}
-
The URI requested by the client is longer than the server is willing to interpret.
-
{{HTTPStatus(415, "415 Unsupported Media Type")}}
-
The media format of the requested data is not supported by the server, so the server is rejecting the request.
-
{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}
-
The range specified by the Range header field in the request can't be fulfilled; it's possible that the range is outside the size of the target URI's data.
-
{{HTTPStatus(417, "417 Expectation Failed")}}
-
This response code means the expectation indicated by the Expect request header field can't be met by the server.
-
{{HTTPStatus(418, "418 I'm a teapot")}}
-
The server refuses the attempt to brew coffee with a teapot.
-
{{HTTPStatus(421, "421 Misdirected Request")}}
-
The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.
-
{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})
-
The request was well-formed but was unable to be followed due to semantic errors.
-
{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})
-
The resource that is being accessed is locked.
-
{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})
-
The request failed due to failure of a previous request.
-
{{HTTPStatus(426, "426 Upgrade Required")}}
-
The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an {{HTTPHeader("Upgrade")}} header in a 426 response to indicate the required protocol(s).
-
{{HTTPStatus(428, "428 Precondition Required")}}
-
The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.
-
{{HTTPStatus(429, "429 Too Many Requests")}}
-
The user has sent too many requests in a given amount of time ("rate limiting").
-
{{HTTPStatus(431, "431 Request Header Fields Too Large")}}
-
The server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.
-
{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}
-
The user requests an illegal resource, such as a web page censored by a government.
-
- -

Server error responses

- -
-
{{HTTPStatus(500, "500 Internal Server Error")}}
-
The server has encountered a situation it doesn't know how to handle.
-
{{HTTPStatus(501, "501 Not Implemented")}}
-
The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD.
-
{{HTTPStatus(502, "502 Bad Gateway")}}
-
This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.
-
{{HTTPStatus(503, "503 Service Unavailable")}}
-
The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This responses should be used for temporary conditions and the Retry-After: HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.
-
{{HTTPStatus(504, "504 Gateway Timeout")}}
-
This error response is given when the server is acting as a gateway and cannot get a response in time.
-
{{HTTPStatus(505, "505 HTTP Version Not Supported")}}
-
The HTTP version used in the request is not supported by the server.
-
{{HTTPStatus(506, "506 Variant Also Negotiates")}}
-
The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.
-
{{HTTPStatus(507, "507 Insufficient Storage")}}
-
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
-
{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
-
The server detected an infinite loop while processing the request.
-
{{HTTPStatus(510, "510 Not Extended")}}
-
Further extensions to the request are required for the server to fulfill it.
-
{{HTTPStatus(511, "511 Network Authentication Required")}}
-
The 511 status code indicates that the client needs to authenticate to gain network access.
-
- -

See also

- - -- cgit v1.2.3-54-g00ecf