diff options
Diffstat (limited to 'files/ru/web/http')
44 files changed, 99 insertions, 99 deletions
diff --git a/files/ru/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/ru/web/http/basics_of_http/identifying_resources_on_the_web/index.html index 5109191113..debd21c8bf 100644 --- a/files/ru/web/http/basics_of_http/identifying_resources_on_the_web/index.html +++ b/files/ru/web/http/basics_of_http/identifying_resources_on_the_web/index.html @@ -22,7 +22,7 @@ original_slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web_RU <p class="summary">"Объект" (или "цель") HTTP-запроса называется "ресурс", чья природа может быть разной: фото, документ, или что-либо ещё. Каждый ресурс идентифицируется с помощью унифицированного идентификатора ресурса ({{Glossary("URI")}}) используемого повсюду в HTTP для идентификации ресурсов.</p> -<p>Обычно чтобы описать конкретный ресурс (его имя) и его местоположение в Вебе, используется всего один URL (Uniform Resource Locator - Унифицированный локатор ресурса, вид URI, его ещё называеют <em>веб-адресом</em>). Можно добавить, что иногда с помощью специального заголовка {{HTTPHeader("Alt-Svc")}} в ответе на запрос можно попросить клиента перезапросить ресурс с другой локации.</p> +<p>Обычно чтобы описать конкретный ресурс (его имя) и его местоположение в Вебе, используется всего один URL (Uniform Resource Locator - Унифицированный локатор ресурса, вид URI, его ещё называют <em>веб-адресом</em>). Можно добавить, что иногда с помощью специального заголовка {{HTTPHeader("Alt-Svc")}} в ответе на запрос можно попросить клиента перезапросить ресурс с другой локации.</p> <h2 id="URLы_и_URNы">URLы и URNы</h2> @@ -147,7 +147,7 @@ urn:ietf:rfc:7230 <dl> <dt><img alt="Anchor" src="https://mdn.mozillademos.org/files/8023/mdn-url-anchor@x2.png" style="height: 70px; width: 440px;"></dt> - <dd><code>#SomewhereInTheDocument</code> - это "якорь" на другую часть ресурса. Якорь представляет собой что-то вроде "закладки" внутри ресурса, давая браузеру указание показать содержимое с определенного места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе бразуер попытается перейти на время, указанное в якоре. Важно что часть, начинающаяся с # - никогда не пересылается серверу в запросе.</dd> + <dd><code>#SomewhereInTheDocument</code> - это "якорь" на другую часть ресурса. Якорь представляет собой что-то вроде "закладки" внутри ресурса, давая браузеру указание показать содержимое с определенного места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе браузер попытается перейти на время, указанное в якоре. Важно что часть, начинающаяся с # - никогда не пересылается серверу в запросе.</dd> </dl> <h2 id="Заметки_по_использованию">Заметки по использованию</h2> diff --git a/files/ru/web/http/basics_of_http/mime_types/index.html b/files/ru/web/http/basics_of_http/mime_types/index.html index e368e2a496..41b620e326 100644 --- a/files/ru/web/http/basics_of_http/mime_types/index.html +++ b/files/ru/web/http/basics_of_http/mime_types/index.html @@ -25,7 +25,7 @@ translation_of: Web/HTTP/Basics_of_HTTP/MIME_types <pre class="syntaxbox"><var>тип</var>/<var>подтип</var>;<var>параметр</var>=<var>значение</var></pre> -<p>Например, для MIME типов катогории<var> </var><code>text</code>, необязательный параметр <code>charset</code> может быть задан для уточнения кодировки, используемой в документе. Для объявления, что пересылаемый файл имеет кодировку UTF-8, необходимо использовать MIME тип <code>text/plain;charset=UTF-8</code>. При не указании параметра <code>charset</code>, его значение автоматически будет задано, как {{Glossary("ASCII")}} (<code>US</code><code>-</code><code>ASCII</code>), если в настройках браузера не будет определено иначе.</p> +<p>Например, для MIME типов категории<var> </var><code>text</code>, необязательный параметр <code>charset</code> может быть задан для уточнения кодировки, используемой в документе. Для объявления, что пересылаемый файл имеет кодировку UTF-8, необходимо использовать MIME тип <code>text/plain;charset=UTF-8</code>. При не указании параметра <code>charset</code>, его значение автоматически будет задано, как {{Glossary("ASCII")}} (<code>US</code><code>-</code><code>ASCII</code>), если в настройках браузера не будет определено иначе.</p> <p>MIME типы являются нечувствительными к регистру, но традиционно их пишут строчными буквами, за исключением значений параметров.</p> diff --git a/files/ru/web/http/caching/index.html b/files/ru/web/http/caching/index.html index ff4905250b..9e6efe7d3e 100644 --- a/files/ru/web/http/caching/index.html +++ b/files/ru/web/http/caching/index.html @@ -11,7 +11,7 @@ original_slug: Web/HTTP/Кэширование --- <div>{{HTTPSidebar}}</div> -<p><strong>Производительность веб-сайтов и приложений можно значительно повысить за счет повторного использования ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой траффик, уменьшая тем самым время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более отзывчивыми.</strong></p> +<p><strong>Производительность веб-сайтов и приложений можно значительно повысить за счет повторного использования ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой трафик, уменьшая тем самым время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более отзывчивыми.</strong></p> <h2 id="Различные_виды_кеширования">Различные виды кеширования</h2> @@ -31,7 +31,7 @@ original_slug: Web/HTTP/Кэширование <h3 id="Общий_shared_прокси-кеш">Общий (shared) прокси-кеш</h3> -<p>Кеш совместного использования — это кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой траффик и время ожидания.</p> +<p>Кеш совместного использования — это кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.</p> <h2 id="Цели_кеширования">Цели кеширования</h2> @@ -99,7 +99,7 @@ Cache-Control: public <h2 id="Свежесть_сохраненной_копии"><a id="Freshness" name="Freshness">Свежесть сохраненной копии</a></h2> -<p>Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют <em>вытеснением данных из кеша</em> (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохраненной копии. До его истечения ресурс считается <em>свежим </em>(fresh), после — <em>устаревшим </em>(stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении ее срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком {{HTTPHeader("If-None-Match")}} на случай, если копия все еще актуальна. Если это так, сервер возвращает заголовок {{HTTPStatus("304")}} <code>Not Modified</code> («не изменялось»), а тело ресурса не посылает, экономя тем самым траффик.</p> +<p>Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют <em>вытеснением данных из кеша</em> (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохраненной копии. До его истечения ресурс считается <em>свежим </em>(fresh), после — <em>устаревшим </em>(stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении ее срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком {{HTTPHeader("If-None-Match")}} на случай, если копия все еще актуальна. Если это так, сервер возвращает заголовок {{HTTPStatus("304")}} <code>Not Modified</code> («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.</p> <p>Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:</p> diff --git a/files/ru/web/http/conditional_requests/index.html b/files/ru/web/http/conditional_requests/index.html index 547d4a80af..e515d13e24 100644 --- a/files/ru/web/http/conditional_requests/index.html +++ b/files/ru/web/http/conditional_requests/index.html @@ -5,11 +5,11 @@ translation_of: Web/HTTP/Conditional_requests --- <p>{{HTTPSidebar}}</p> -<p class="summary">В HTTP есть понятие <em>условных запросов</em>, в которых результат, и даже успех запрос, могут быть изменены с помощью сравнения затронутых ресурсов со значением <em>валидатора</em>. Такие запросы могут быть полезными для валидации контента в кеше, и избавления от бесполезного контроля, чтобы проверить целостность документа, например, пока длится загрузка, или пока предовращается потеря обновлений, пока выгружаются или изменяются файлы на сервере.</p> +<p class="summary">В HTTP есть понятие <em>условных запросов</em>, в которых результат, и даже успех запрос, могут быть изменены с помощью сравнения затронутых ресурсов со значением <em>валидатора</em>. Такие запросы могут быть полезными для валидации контента в кеше, и избавления от бесполезного контроля, чтобы проверить целостность документа, например, пока длится загрузка, или пока предотвращается потеря обновлений, пока выгружаются или изменяются файлы на сервере.</p> <h2 id="Принципы">Принципы</h2> -<p>Условные запросы HTTP это запросы, которые выполняся по разному, в зависимости значения особых заголовков. Эти заголовки определяют предусловие, и результат запроса будет разным, если условие согласовано или нет.</p> +<p>Условные запросы HTTP это запросы, которые выполняются по разному, в зависимости значения особых заголовков. Эти заголовки определяют предусловие, и результат запроса будет разным, если условие согласовано или нет.</p> <p>Отличие в поведении определяется используемым методом, и набором заголовков для предусловий:</p> diff --git a/files/ru/web/http/connection_management_in_http_1.x/index.html b/files/ru/web/http/connection_management_in_http_1.x/index.html index 16ce498108..4b75db2059 100644 --- a/files/ru/web/http/connection_management_in_http_1.x/index.html +++ b/files/ru/web/http/connection_management_in_http_1.x/index.html @@ -41,7 +41,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x <p>У постоянных соединений есть свои недочеты; даже работая вхолостую, они потребляют ресурсы сервера, а при высокой нагрузке могут проводиться {{glossary("DoS attack", "DoS attacks")}}. В таких случаях большую эффективность могут обеспечить не постоянные соединения, которые закрываются как только освободятся.</p> -<p>Соединеня HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p> +<p>Соединения HTTP/1.0 по умолчанию не являются постоянными. Для превращения их в постоянные надо присвоить заголовку {{HTTPHeader("Connection")}} значение, отличное от <code>close</code> - обычно <code>retry-after.</code></p> <p>В HTTP/1.1 соединения являются постоянными по умолчанию, так что этот заголовок больше не требуется (но часто добавляется в качестве защитной меры на случай, если потребуется откат к HTTP/1.0).</p> @@ -51,7 +51,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x <p>Конвейерная обработка HTTP в современных браузерах не активирована по умолчанию:</p> <ul> - <li><a href="https://en.wikipedia.org/wiki/Proxy_server">Прокси</a> с багами все еще встречаются, что приводит к странным и непредсказуемым явлениям, которые веб-разработчикам трудно предсказать и диагносцировать.</li> + <li><a href="https://en.wikipedia.org/wiki/Proxy_server">Прокси</a> с багами все еще встречаются, что приводит к странным и непредсказуемым явлениям, которые веб-разработчикам трудно предсказать и диагностировать.</li> <li>Конвейерную обработку сложно правильно реализовать: объем передаваемых ресурсов, используемая <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a> и эффективная пропускная способность имеют непосредственное влияние на те улучшения, что обеспечиваются конвейерной обработкой. Конвейерная обработка HTTP, таким образом, дает существенное улучшение не во всех случаях.</li> <li>Конвейерная обработка подвержена проблеме <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a>.</li> </ul> @@ -73,7 +73,7 @@ translation_of: Web/HTTP/Connection_management_in_HTTP_1.x <p>Не используйте этот устаревший метод без крайней необходимости; вместо этого переходите на HTTP/2. В HTTP/2 доменное разделение больше не требуется: соединение HTTP/2 соединение прекрасно работает с параллельными неприоритезированными запросами. Доменное разделение даже вредит производительности. Большинство реализаций HTTP/2 использует метод, называемый <a href="I wonder if it's related to the nobash/nobreak/nopick secret exit s of Elrond's chambers.">слиянием соединений (connection coalescing</a>) для возврата конечного доменного разделения.</p> </div> -<p>Поскольку соединение HTTP/1.x является последовательными запросами, даже без упорядочивания, оно не может быть оптимальным без наличия достаточно большой пропускной способности. Браузеры находят решение в открытии нескольких соедининий к каждому домену с отсылкой параллельных запросов. По умолчанию это когда-то было 2-3 соединения, но сейчас их число возросло примерно до 6 параллельных соединений. При попытке использовать большее количество есть риск спровоцировать защиту от <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> со стороны сервера.</p> +<p>Поскольку соединение HTTP/1.x является последовательными запросами, даже без упорядочивания, оно не может быть оптимальным без наличия достаточно большой пропускной способности. Браузеры находят решение в открытии нескольких соединений к каждому домену с отсылкой параллельных запросов. По умолчанию это когда-то было 2-3 соединения, но сейчас их число возросло примерно до 6 параллельных соединений. При попытке использовать большее количество есть риск спровоцировать защиту от <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> со стороны сервера.</p> <p>Если сервер хочет иметь более быстрый ответ от веб-сайта или приложения, он может открыть больше соединений. Например, вместо того, чтобы иметь все ресурсы на одном домене, скажем, <code>www.example.com</code>, он может распределить их по нескольким доменам, <code>www1.example.com</code>, <code>www2.example.com</code>, <code>www3.example.com</code>. Каждый из этих доменов разрешается на том же сервере, и веб-браузер откроет 6 соединений к каждому (в нашем примере число соединений возрастет до 18). Этот метод называют доменным разделением (<em>domain sharding)</em>.</p> diff --git a/files/ru/web/http/content_negotiation/index.html b/files/ru/web/http/content_negotiation/index.html index d5228526aa..28d401e3ad 100644 --- a/files/ru/web/http/content_negotiation/index.html +++ b/files/ru/web/http/content_negotiation/index.html @@ -11,7 +11,7 @@ translation_of: Web/HTTP/Content_negotiation <h2 id="Принципы_согласования_контента">Принципы согласования контента</h2> -<p>Конкретный документ называется <em>ресурсом</em>. Когда клиент хочет его получить, он запрашивает его используя его URL. Сервер использует этот URL, чтобы выбрать один из возможных вариантов - каждый вариант, назывется <em>представлением</em>, – и возвращает этот вариант клиенту. Ресурс в общем, а также каждое из представлений, имеют определенный URL. Выбор конкретного представления при вызове ресурса определяется механизмом <em>согласования контента</em> и существует несколько способов согласования между клиентом и сервером.</p> +<p>Конкретный документ называется <em>ресурсом</em>. Когда клиент хочет его получить, он запрашивает его используя его URL. Сервер использует этот URL, чтобы выбрать один из возможных вариантов - каждый вариант, называется <em>представлением</em>, – и возвращает этот вариант клиенту. Ресурс в общем, а также каждое из представлений, имеют определенный URL. Выбор конкретного представления при вызове ресурса определяется механизмом <em>согласования контента</em> и существует несколько способов согласования между клиентом и сервером.</p> <p><img alt="" src="https://mdn.mozillademos.org/files/16156/HTTPNego_ru.png" style="height: 311px; width: 767px;"></p> @@ -26,13 +26,13 @@ translation_of: Web/HTTP/Content_negotiation <h2 id="Согласование_на_основе_сервера">Согласование на основе сервера</h2> -<p>В <em>согласовании на стороне сервера</em> или <em>упреждающем согласовании</em>, браузер (или любое другое клиентское приложение) посылае несколько заголовков HTTP наряду с URL. Эти заголовки описывают предпочтения пользователя. Сервер использует их в качестве посказок для внутреннего алгоритма, который выбирает наиболее подходящее представление ресурса, чтобы предоставить его клиенту. Реализация алгоритма в стандарт не входит и полностью зависит от сервера. Для примера, смотрите <a class="external" href="http://httpd.apache.org/docs/2.2/en/content-negotiation.html#algorithm">алгоритм согласования Apache 2.2</a>.</p> +<p>В <em>согласовании на стороне сервера</em> или <em>упреждающем согласовании</em>, браузер (или любое другое клиентское приложение) посылает несколько заголовков HTTP наряду с URL. Эти заголовки описывают предпочтения пользователя. Сервер использует их в качестве подсказок для внутреннего алгоритма, который выбирает наиболее подходящее представление ресурса, чтобы предоставить его клиенту. Реализация алгоритма в стандарт не входит и полностью зависит от сервера. Для примера, смотрите <a class="external" href="http://httpd.apache.org/docs/2.2/en/content-negotiation.html#algorithm">алгоритм согласования Apache 2.2</a>.</p> <p><img alt="" src="https://mdn.mozillademos.org/files/13791/HTTPNegoServer.png" style="height: 380px; width: 767px;"></p> <p>Стандарт HTTP/1.1 определяет список стандартных заголовков которые используются в этом механизме согласования – ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Хотя, строго говоря, {{HTTPHeader("User-Agent")}} не находится в этом списке, в некоторых случаях он используется, чтобы послать определённое представление запрошенного ресурса, несмотря на то, что это и не является хорошей практикой. Сервер использует заголовок {{HTTPHeader("Vary")}} чтобы обозначить, какие заголовки он использовал для согласования (точнее, ассоциированные с ними заголовки ответа), чтобы <a href="/en-US/docs/Web/HTTP/Caching">кэширование</a> работало оптимально.</p> -<p>В дополнение к этим, есть предложение добавить больше заголовков в список доступным, так называемые Подсказки Клиента (Client Hints). Они будут предоставлять информацио о типе устройства на котором они используются (например, будет это настольный компьютер или мобильное устройство).</p> +<p>В дополнение к этим, есть предложение добавить больше заголовков в список доступным, так называемые Подсказки Клиента (Client Hints). Они будут предоставлять информацию о типе устройства на котором они используются (например, будет это настольный компьютер или мобильное устройство).</p> <p>Согласование на стороне сервера является самым популярным способом согласования контента, но у него есть несколько недостатков:</p> @@ -44,7 +44,7 @@ translation_of: Web/HTTP/Content_negotiation <h3 id="Заголовок_Accept">Заголовок <code>Accept</code></h3> -<p>Заголовок {{HTTPHeader("Accept")}} перечисляет MIME типы содержимого ресурса, которые клиент желает получить. Он представляет список MIME типов, разделенный запятыми, каждый из которых, опционально, снабжён коэффицентом желательности – параметром, определяющим относительный уровень желательности среди разных MIME типов.</p> +<p>Заголовок {{HTTPHeader("Accept")}} перечисляет MIME типы содержимого ресурса, которые клиент желает получить. Он представляет список MIME типов, разделенный запятыми, каждый из которых, опционально, снабжён коэффициентом желательности – параметром, определяющим относительный уровень желательности среди разных MIME типов.</p> <p>{{HTTPHeader("Accept")}} определяется браузером, или любым другим клиентом, и может изменяться в зависимости от контекста, например, при получении страницы HTML, изображения, видео или скрипта – его содержимое будет различаться при запросе документа из строки адреса, через тег {{ HTMLElement("img") }}, {{ HTMLElement("video") }} или {{ HTMLElement("audio") }}. Браузеры могут использовать любое значение, которые они считают наиболее подходящим; можете ознакомиться со списком <a href="/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values">значений по умолчанию, используемых распространенными браузерами</a>.</p> @@ -54,7 +54,7 @@ translation_of: Web/HTTP/Content_negotiation <p>Перед вами <strong>экспериментальная</strong> технология под названием <em>Client Hints (Подсказки Клиента)</em>, реализуемая на данный момент только в Chrome 46 и более поздних версиях</p> </div> -<p>Экспериментальный заголовок {{HTTPHeader("Accept-CH")}} перечисляет конфигурфцию клиента, которая может быть использована сервером для выбора подходящего ответа. Определённые значения:</p> +<p>Экспериментальный заголовок {{HTTPHeader("Accept-CH")}} перечисляет конфигурацию клиента, которая может быть использована сервером для выбора подходящего ответа. Определённые значения:</p> <table class="standard-table"> <thead> @@ -83,7 +83,7 @@ translation_of: Web/HTTP/Content_negotiation <p>Заголовок {{HTTPHeader("Accept-Charset")}} указывает серверу какие кодировки текста поддерживает клиент. По традиции он имеет своё значение для каждой локали браузера, например, <code>ISO-8859-1,utf-8;q=0.7,*;q=0.7</code> установлен для западноевропейской локали.</p> -<p>В настоящее время, UTF-8 имеет серьёзную поддержку, является предпочтительным способом кодировки текста и гарантирует лучшую конфеденциальность за счет уменьшения разнообразия конфигураций, поэтому большая часть браузеров пропускает заголовок <code>Accept-Charset</code>: Internet Explorer 8, Safari 5, Opera 11 и Firefox 10 отказались от этого заголовка в запросах.</p> +<p>В настоящее время, UTF-8 имеет серьёзную поддержку, является предпочтительным способом кодировки текста и гарантирует лучшую конфиденциальность за счет уменьшения разнообразия конфигураций, поэтому большая часть браузеров пропускает заголовок <code>Accept-Charset</code>: Internet Explorer 8, Safari 5, Opera 11 и Firefox 10 отказались от этого заголовка в запросах.</p> <h3 id="Заголовок_Accept-Encoding">Заголовок <code>Accept-Encoding</code></h3> diff --git a/files/ru/web/http/cookies/index.html b/files/ru/web/http/cookies/index.html index 15aedf93b7..f18f00eda4 100644 --- a/files/ru/web/http/cookies/index.html +++ b/files/ru/web/http/cookies/index.html @@ -121,7 +121,7 @@ console.log(document.cookie); <pre class="brush: html"><img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre> -<p>Теперь, если вы зашли в свой банковский аккаунт, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для защиты от этого изпользуется ряд методов:</p> +<p>Теперь, если вы зашли в свой банковский аккаунт, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для защиты от этого используется ряд методов:</p> <ul> <li>Как и при {{Glossary("XSS")}}, важна фильтрация входящей информации.</li> diff --git a/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html index 8a59413663..63532d0183 100644 --- a/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html +++ b/files/ru/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html @@ -25,7 +25,7 @@ translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin <p>Проще говоря, источник делает запрос который не совпадает ни с одним из источников разрешенных заголовком - {{HTTPHeader("Access-Control-Allow-Origin")}}.</p> -<p>Эта ошибка также может произойти, если ответ содежит более одного заголовка <code>Access-Control-Allow-Origin</code>.</p> +<p>Эта ошибка также может произойти, если ответ содержит более одного заголовка <code>Access-Control-Allow-Origin</code>.</p> <p>Если сервис, к которому ваш код обращается с помощью CORS запроса находится под вашим контролем, убедитесь что он настроен для включения в себя вашего источника в заголовке <code>Access-Control-Allow-Origin</code> и что в ответах от сервера присутствует только один такой заголовок. Заголовок принимает список источников, поэтому указать новый источник совсем не сложно.</p> diff --git a/files/ru/web/http/cors/index.html b/files/ru/web/http/cors/index.html index ee6cfda506..58ed9b8b87 100644 --- a/files/ru/web/http/cors/index.html +++ b/files/ru/web/http/cors/index.html @@ -23,7 +23,7 @@ translation_of: Web/HTTP/CORS <h2 id="Какие_запросы_используют_CORS">Какие запросы используют CORS?</h2> -<p>Этот <a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">cтандарт сross-origin обмена</a> используется для разрешения кросс-сайтовых HTTP запросов для:</p> +<p>Этот <a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">стандарт сross-origin обмена</a> используется для разрешения кросс-сайтовых HTTP запросов для:</p> <ul> <li>Вызова {{domxref("XMLHttpRequest")}} или <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> APIs в кросс-сайт манере, как описано выше.</li> @@ -38,7 +38,7 @@ translation_of: Web/HTTP/CORS <h2 id="Обзор_функциональности">Обзор функциональности</h2> -<p>Стандарт Cross-Origin Resource Sharing работает с помощью добавления новых <a href="/en-US/docs/Web/HTTP/Headers">HTTP-заголовков</a>, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных от {{HTTPMethod("GET")}} или для {{HTTPMethod("POST")}} запросов, использующих определнные <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME-</a>типы), спецификация требует, чтобы браузеры "предпроверяли" запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запроса {{HTTPMethod("OPTIONS")}} и затем, поверх "подтверждения" с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли "полномочия" (включая <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> и HTTP Authentication данные) быть отправлены с запросом.</p> +<p>Стандарт Cross-Origin Resource Sharing работает с помощью добавления новых <a href="/en-US/docs/Web/HTTP/Headers">HTTP-заголовков</a>, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных от {{HTTPMethod("GET")}} или для {{HTTPMethod("POST")}} запросов, использующих определенные <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME-</a>типы), спецификация требует, чтобы браузеры "предпроверяли" запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запроса {{HTTPMethod("OPTIONS")}} и затем, поверх "подтверждения" с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли "полномочия" (включая <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> и HTTP Authentication данные) быть отправлены с запросом.</p> <p>Следующая секция описывает сценарии, а также предоставляет анализ использования HTTP-заголовков. </p> @@ -209,7 +209,7 @@ function callOtherDomain(){ <p><img alt="" src="https://mdn.mozillademos.org/files/16753/preflight_correct.png" style="height: 553px; width: 521px;"></p> <div class="blockIndicator note"> -<p><strong>Замечнаие:</strong> как описано ниже, фактический <code>POST</code> запрос не включает <code>Access-Control-Request-*</code> заголовки; они нужны только для <code>OPTIONS</code> запроса.</p> +<p><strong>Замечание:</strong> как описано ниже, фактический <code>POST</code> запрос не включает <code>Access-Control-Request-*</code> заголовки; они нужны только для <code>OPTIONS</code> запроса.</p> </div> <p>Давайте посмотрим на полный обмен между клиентом и сервером. Первый обмен - это <em>предварительный</em> <em>запрос/ответ</em>:</p> @@ -330,7 +330,7 @@ Access-Control-Max-Age: 86400</pre> <h3 id="Запросы_с_учетными_данными">Запросы с учетными данными</h3> -<p>Наиболее интересная возможность, предоставляемая как {{domxref("XMLHttpRequest")}}, так и <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> и CORS - это возможность делать "проверенные" запросы, которые осведомленны о файлах <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookie</a> и информации HTTP аутентификаци. По умолчанию, в кросс-сайтовых {{domxref("XMLHttpRequest")}} или <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> вызовах, браузеры <strong>не </strong>отправляют учетные данные. Конкретный флаг должен быть установлен для объекта {{domxref("XMLHttpRequest")}} или конструктора {{domxref("Request")}} при его вызове.</p> +<p>Наиболее интересная возможность, предоставляемая как {{domxref("XMLHttpRequest")}}, так и <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> и CORS - это возможность делать "проверенные" запросы, которые осведомлены о файлах <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookie</a> и информации HTTP аутентификации. По умолчанию, в кросс-сайтовых {{domxref("XMLHttpRequest")}} или <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> вызовах, браузеры <strong>не </strong>отправляют учетные данные. Конкретный флаг должен быть установлен для объекта {{domxref("XMLHttpRequest")}} или конструктора {{domxref("Request")}} при его вызове.</p> <p>В этом примере контент, изначально загруженный из <code class="plain">http://foo.example,</code> выполняет простой GET запрос к ресурсу <code class="plain">http://bar.other,</code> который устанавливает файлы сookie. Содержимое на foo.example может содержать такой JavaScript:</p> @@ -350,7 +350,7 @@ function callOtherDomain(){ <p><img alt="" src="https://mdn.mozillademos.org/files/14291/cred-req.png" style="height: 223px; width: 521px;"></p> -<p>Вот пример обмена между клентом и сервером:</p> +<p>Вот пример обмена между клиентом и сервером:</p> <pre class="brush: none notranslate">GET /resources/access-control-with-credentials/ HTTP/1.1 Host: bar.other diff --git a/files/ru/web/http/csp/index.html b/files/ru/web/http/csp/index.html index b0d13ff4fc..c5c1d48294 100644 --- a/files/ru/web/http/csp/index.html +++ b/files/ru/web/http/csp/index.html @@ -73,7 +73,7 @@ translation_of: Web/HTTP/CSP <ul> <li>Изображения могут быть получены из любого источника (источник - "*").</li> <li>Другие медиа-файлы доступны только с media1.com и media2.com (но не с их поддоменов).</li> - <li>Имсполняемый код доступен только с userscripts.example.com.</li> + <li>Исполняемый код доступен только с userscripts.example.com.</li> </ul> <h3 id="Пример_4">Пример 4</h3> @@ -179,7 +179,7 @@ translation_of: Web/HTTP/CSP <p>{{Compat("http.headers.csp")}}</p> -<p>Для некоторых версий Safari существует специфическая невсовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнет блокировать и создавать ложно-положительные отчеты о нарушении политики для всего контента, как с запрашеваемого источника, так и из внешних источников.</p> +<p>Для некоторых версий Safari существует специфическая несовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнет блокировать и создавать ложно-положительные отчеты о нарушении политики для всего контента, как с запрашиваемого источника, так и из внешних источников.</p> <p>Смотрите также:</p> diff --git a/files/ru/web/http/feature_policy/index.html b/files/ru/web/http/feature_policy/index.html index c97e13a4e5..972b15c168 100644 --- a/files/ru/web/http/feature_policy/index.html +++ b/files/ru/web/http/feature_policy/index.html @@ -9,7 +9,7 @@ translation_of: Web/HTTP/Feature_Policy <h2 id="Краткое_описание">Краткое описание</h2> -<p>Заголовок Feature Policy предоставляет механизм для ясного указания функций, используемых или не используемых вашим ваб-сайтом. Это позволяет закрепить лучшие практики, даже если кодовая база развивается с течением времени, а также более безопасно включать сторонний контент, ограничивая доступные функции.</p> +<p>Заголовок Feature Policy предоставляет механизм для ясного указания функций, используемых или не используемых вашим веб-сайтом. Это позволяет закрепить лучшие практики, даже если кодовая база развивается с течением времени, а также более безопасно включать сторонний контент, ограничивая доступные функции.</p> <p>С помощью заголовка Feature Policy вы можете включить набор "политик" для браузера, чтобы использовать определенные функции, необходимые веб-сайту. Эти политики определяют какие API сайта могут получать доступ или изменять поведение по умолчанию для определенных функций.</p> diff --git a/files/ru/web/http/feature_policy/using_feature_policy/index.html b/files/ru/web/http/feature_policy/using_feature_policy/index.html index bdf46e1be5..b2dc5d8792 100644 --- a/files/ru/web/http/feature_policy/using_feature_policy/index.html +++ b/files/ru/web/http/feature_policy/using_feature_policy/index.html @@ -13,9 +13,9 @@ translation_of: Web/HTTP/Feature_Policy/Using_Feature_Policy <p>Для каждой функции, контролируемой функциональной политикой, браузер отслеживает список источников происхождения, для документов которого, эта функция разрешена. Если разработчик не определил политику для функциональности, тогда будет использован список разрешенных источников по умолчанию. Этот список специфичен для каждой функциональности. </p> -<h2 id="Описание_полититки">Описание полититки</h2> +<h2 id="Описание_политики">Описание политики</h2> -<p>Политика определяется, используя набор индивидуальных установочных директив. Установочная директива - это комбинация имен определяемых функциональностей, со списком источников происхождения, которым разрешается достук к указанной функциональности. Имена функциональностей в политике разделяются точкой с запятой.</p> +<p>Политика определяется, используя набор индивидуальных установочных директив. Установочная директива - это комбинация имен определяемых функциональностей, со списком источников происхождения, которым разрешается доступ к указанной функциональности. Имена функциональностей в политике разделяются точкой с запятой.</p> <h3 id="список_доступа">список доступа</h3> @@ -26,10 +26,10 @@ translation_of: Web/HTTP/Feature_Policy/Using_Feature_Policy <li><code>'self'</code>: Функциональность разрешается в документе и всем вложенным в него браузерным контекстам (элементам <code>iframes</code>) общего с этим документом источником происхождения.</li> <li><code>'src'</code>: (только для элемента<code> iframe</code> с атрибутом <code>allow</code>) Функциональность доступна в этом фрейме, при условии, что загруженный в него документ происходит из того же источника, что и URL в атрибуте {{HTMLElement('iframe','src','#Attributes')}} элемента <code>iframe</code>.</li> <li><code>'none'</code>: Функциональность отключена как для высокоуровневых документов, так и для вложенных в него контекстов (<code>iframes</code>).</li> - <li><origin(s)>: Функциональность доступна для специфичных источников происхождения, указываемых разработчиком (к примеру, https://example.com), раздедяемые между собой пробелом.</li> + <li><origin(s)>: Функциональность доступна для специфичных источников происхождения, указываемых разработчиком (к примеру, https://example.com), разделяемые между собой пробелом.</li> </ul> -<p>Значение <code>*</code> (доступность функциональности для всех источников) или <code>'none'</code> (не доступность функциональности для всех источников), можут использоваться только однократно, в то время как, значения <code>'self'</code> и <code>'src'</code> могут быть использованы с одним или несколькими источниками происхождения.</p> +<p>Значение <code>*</code> (доступность функциональности для всех источников) или <code>'none'</code> (не доступность функциональности для всех источников), может использоваться только однократно, в то время как, значения <code>'self'</code> и <code>'src'</code> могут быть использованы с одним или несколькими источниками происхождения.</p> <p>Каждая функциональность определяется со своим списком разрешений по умолчанию, который содержит одно из значений:</p> @@ -60,7 +60,7 @@ translation_of: Web/HTTP/Feature_Policy/Using_Feature_Policy <pre class="brush: bash">Feature-Policy: geolocation 'none'</pre> -<p>Несколько функциональностей можно контролировать одновременно, отправив один HTTP заголовок, разделяющий точкой с запятой между собой список установочных директив, или отпраить отдельный заголовок для каждой установочной директивы.</p> +<p>Несколько функциональностей можно контролировать одновременно, отправив один HTTP заголовок, разделяющий точкой с запятой между собой список установочных директив, или отправить отдельный заголовок для каждой установочной директивы.</p> <p>К примеру, ниже директивы идентичны:</p> @@ -104,9 +104,9 @@ Feature-Policy: camera *; <p>Отключение функциональности в политике является односторонним. Если функциональность не доступна (отключена) для дочернего фрейма его родителем, дочерний фрейм не может это отменить, и ни его потомки.</p> -<h2 id="Применение_новейших_решений_для_наилутшего_пользовательского_впечатления">Применение новейших решений для наилутшего пользовательского впечатления</h2> +<h2 id="Применение_новейших_решений_для_наилучшего_пользовательского_впечатления">Применение новейших решений для наилучшего пользовательского впечатления</h2> -<p>Трудно создать веб сайт, который использует новейшие решения и предлагает отличную производительность. Со временем, эволюционируя, сайту может даже труднее обеспечивать наилутшие пользовательские впечатления. Используйте функциональные политики для определения новейших решений, и полагайтесь на современные браузеры в предотвращении негативных изменений.</p> +<p>Трудно создать веб сайт, который использует новейшие решения и предлагает отличную производительность. Со временем, эволюционируя, сайту может даже труднее обеспечивать наилучшие пользовательские впечатления. Используйте функциональные политики для определения новейших решений, и полагайтесь на современные браузеры в предотвращении негативных изменений.</p> <p>Существуют несколько функциональных политик, спроектированных для предоставления функциональности, но которые могут негативно влиять на впечатления пользователя. Ими являются:</p> @@ -121,7 +121,7 @@ Feature-Policy: camera *; <p>Для исключения поломки веб контента, значения по умолчанию для таких функциональных политик, позволяют функциональности быть использованной для всех источников происхождения. То есть, списком разрешений по умолчанию является <code>'*'</code> для каждой функциональности. Предотвращение использования неоптимальной функциональности, требует явного определения политики, которая отключает функциональности.</p> -<p>Для нового контента можно начать разработку с политикой, которая отключает все функциональности. Такой подход гаранитрует, что ни одна из функциональностей не включена. При применении политики для существующего контента, тестирование работы наиболее желательный вариант для ожидаемой проверки работоспособности. Это особенно важно для встроенных или сторонних контентов, которых разработчик не может контролировать.</p> +<p>Для нового контента можно начать разработку с политикой, которая отключает все функциональности. Такой подход гарантирует, что ни одна из функциональностей не включена. При применении политики для существующего контента, тестирование работы наиболее желательный вариант для ожидаемой проверки работоспособности. Это особенно важно для встроенных или сторонних контентов, которых разработчик не может контролировать.</p> <p>Для включения правоприменения всех новейших решений, определяется политика ниже.</p> @@ -141,5 +141,5 @@ Feature-Policy: camera *; <li>Атрибут {{HTMLElement('iframe','allow','#Attributes')}} элемента <code>iframe</code></li> <li>Заголовок {{HTTPHeader("Content-Security-Policy")}} </li> <li>Заголовок {{HTTPHeader("Referrer-Policy")}}</li> - <li><a href="/en-US/docs/Web/Privacy">Конфеденциальность, разрешения и информационная безопасность</a></li> + <li><a href="/en-US/docs/Web/Privacy">Конфиденциальность, разрешения и информационная безопасность</a></li> </ul> diff --git a/files/ru/web/http/headers/accept-charset/index.html b/files/ru/web/http/headers/accept-charset/index.html index 5201aa7df9..a8008ec1b8 100644 --- a/files/ru/web/http/headers/accept-charset/index.html +++ b/files/ru/web/http/headers/accept-charset/index.html @@ -6,7 +6,7 @@ original_slug: Web/HTTP/Заголовки/Accept-Charset --- <div>{{HTTPSidebar}}</div> -<p>Заголовок <strong><code>Accept-Charset</code></strong> запроса HTTP сообщает какую кодировку клиент может понять. Используя <a href="/en-US/docs/Web/HTTP/Content_negotiation">согласование контента</a>, сервер выбирает один из предложенных вариантов, использует его и информирует клиент о своем выборе в {{HTTPHeader("Content-Type")}} ответном заголовке. Браузер обычно не устанавливает этот заголовок, т.к. значение по умолчанию для каждого контентного типа обычно коректный и передача его позволит с большей легкостью получить цифровой отпечаток.</p> +<p>Заголовок <strong><code>Accept-Charset</code></strong> запроса HTTP сообщает какую кодировку клиент может понять. Используя <a href="/en-US/docs/Web/HTTP/Content_negotiation">согласование контента</a>, сервер выбирает один из предложенных вариантов, использует его и информирует клиент о своем выборе в {{HTTPHeader("Content-Type")}} ответном заголовке. Браузер обычно не устанавливает этот заголовок, т.к. значение по умолчанию для каждого контентного типа обычно корректный и передача его позволит с большей легкостью получить цифровой отпечаток.</p> <p>Если сервер не может обслужить никакую из предоставленных кодировок, теоретически он может вернуть {{HTTPStatus("406")}} (Not Acceptable) код ошибки. Но, для более лучшего пользовательского опыта, это редко делается и более частый способ в этом случае, это просто игнорирование заголовка <code>Accept-Charset</code>.</p> diff --git a/files/ru/web/http/headers/accept-language/index.html b/files/ru/web/http/headers/accept-language/index.html index 493d22e849..8cce5856b6 100644 --- a/files/ru/web/http/headers/accept-language/index.html +++ b/files/ru/web/http/headers/accept-language/index.html @@ -6,7 +6,7 @@ original_slug: Web/HTTP/Заголовки/Accept-Language --- <div>{{HTTPSidebar}}</div> -<div>{{Glossary("HTTP-заголовок")}} Запрос <strong><code>Accept-Language</code></strong> сообщает серверу, какие языки клиент понимает и какая локаль предпочтительнее (имеются в виду естественные языки, такие как английский, а не языки программирования). Используя механизм обсуждения содержимого (<a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a>), сервер выбирает один из предложенных вариантов, использует его и информирует клиента о своем выборе при помощи заголовка ответа {{HTTPHeader("Content-Language")}}. Браузеры устанавливают соответствующие значения для данного заголовка, исходя из языка пользовательсокого интерфейса, и, даже если у пользователя есть возможность изменить значение заголовка <strong><code>Accept-Language</code></strong>, это происходит редко (и не одобряется, так как ведет.к идентификации).</div> +<div>{{Glossary("HTTP-заголовок")}} Запрос <strong><code>Accept-Language</code></strong> сообщает серверу, какие языки клиент понимает и какая локаль предпочтительнее (имеются в виду естественные языки, такие как английский, а не языки программирования). Используя механизм обсуждения содержимого (<a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a>), сервер выбирает один из предложенных вариантов, использует его и информирует клиента о своем выборе при помощи заголовка ответа {{HTTPHeader("Content-Language")}}. Браузеры устанавливают соответствующие значения для данного заголовка, исходя из языка пользовательского интерфейса, и, даже если у пользователя есть возможность изменить значение заголовка <strong><code>Accept-Language</code></strong>, это происходит редко (и не одобряется, так как ведет.к идентификации).</div> <div></div> diff --git a/files/ru/web/http/headers/accept-ranges/index.html b/files/ru/web/http/headers/accept-ranges/index.html index 52b098c390..fc91bb80fe 100644 --- a/files/ru/web/http/headers/accept-ranges/index.html +++ b/files/ru/web/http/headers/accept-ranges/index.html @@ -36,7 +36,7 @@ Accept-Ranges: none</pre> <dl> <dt><code>none</code></dt> - <dd>Единица измерения диапазона не поддерживается, что эквивалентно отсутствию диапазона и поэтому редко используется, хотя некоторые браузеры, такие как IE9 используют его для отключения или удаления кнопоки паузы у активной загрузке в менеджере загрузок.</dd> + <dd>Единица измерения диапазона не поддерживается, что эквивалентно отсутствию диапазона и поэтому редко используется, хотя некоторые браузеры, такие как IE9 используют его для отключения или удаления кнопки паузы у активной загрузке в менеджере загрузок.</dd> <dt><code>bytes</code></dt> <dd> <p>Единицей измерения для диапазона являются байты.</p> diff --git a/files/ru/web/http/headers/access-control-allow-headers/index.html b/files/ru/web/http/headers/access-control-allow-headers/index.html index a17c117bc5..d405260c68 100644 --- a/files/ru/web/http/headers/access-control-allow-headers/index.html +++ b/files/ru/web/http/headers/access-control-allow-headers/index.html @@ -13,7 +13,7 @@ original_slug: Web/HTTP/Заголовки/Access-Control-Allow-Headers <p>Заголовок ответа <strong><code>Access-Control-Allow-Headers</code></strong> используется в ответ на {{glossary("preflight request")}}, чтобы указать, какие заголовки HTTP могут использоваться во время фактического запроса.</p> -<p>The {{glossary("simple header", "simple headers")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}} (но только с MIME-типом, найденым в этом значении (исключая параметры), либо <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code> или <code>text/plain</code>), всегда доступны и не должны быть перечислены в этом заголовке.</p> +<p>The {{glossary("simple header", "simple headers")}}, {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Type")}} (но только с MIME-типом, найденным в этом значении (исключая параметры), либо <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code> или <code>text/plain</code>), всегда доступны и не должны быть перечислены в этом заголовке.</p> <p>Этот заголовок обязателен, если запрос содержит заголовок {{HTTPHeader("Access-Control-Request-Headers")}}.</p> diff --git a/files/ru/web/http/headers/access-control-allow-methods/index.html b/files/ru/web/http/headers/access-control-allow-methods/index.html index 8b48a2b470..788d616348 100644 --- a/files/ru/web/http/headers/access-control-allow-methods/index.html +++ b/files/ru/web/http/headers/access-control-allow-methods/index.html @@ -60,7 +60,7 @@ original_slug: Web/HTTP/Заголовки/Access-Control-Allow-Methods <h2 id="Совместимость_с_браузерами">Совместимость с браузерами</h2> -<p class="hidden">Таблица сравнения сгенерирована из структурных данных. Если вы хотите внести вклад в данные, пожалйуста, посмотрите эту ссылку и отправьте <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> pull request.</p> +<p class="hidden">Таблица сравнения сгенерирована из структурных данных. Если вы хотите внести вклад в данные, пожалуйста, посмотрите эту ссылку и отправьте <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> pull request.</p> <p>{{Compat("http.headers.Access-Control-Allow-Methods")}}</p> diff --git a/files/ru/web/http/headers/access-control-allow-origin/index.html b/files/ru/web/http/headers/access-control-allow-origin/index.html index d936294572..402d34c996 100644 --- a/files/ru/web/http/headers/access-control-allow-origin/index.html +++ b/files/ru/web/http/headers/access-control-allow-origin/index.html @@ -37,7 +37,7 @@ Access-Control-Allow-Origin: null <dd>Указывает источник. Может быть указан только один источник.</dd> <dt><code>null</code></dt> <dd>Определяет в качестве источника "null". - <div class="note"><strong>Замечание:</strong> <a href="https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null">Не используйте</a> <code>null</code>: "Может показаться, что вернуть <code>Access-Control-Allow-Origin: "null"</code> безопасно, но сериализация Источника любого ресурса, использующего неиерархическую схему (такие как <code>data:</code> или <code>file:</code>), и изолированные документы, определяются как "null". Многие пользовательские агенты предоставляют таким документам доступ к ответу сзаголовком <code>Access-Control-Allow-Origin: "null"</code>, и любой источник модет создать враждебный документ с Источником "null". Поэтому использования заголовка ACAO со значением "null" следует избегать."</div> + <div class="note"><strong>Замечание:</strong> <a href="https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null">Не используйте</a> <code>null</code>: "Может показаться, что вернуть <code>Access-Control-Allow-Origin: "null"</code> безопасно, но сериализация Источника любого ресурса, использующего неиерархическую схему (такие как <code>data:</code> или <code>file:</code>), и изолированные документы, определяются как "null". Многие пользовательские агенты предоставляют таким документам доступ к ответу с заголовком <code>Access-Control-Allow-Origin: "null"</code>, и любой источник может создать враждебный документ с Источником "null". Поэтому использования заголовка ACAO со значением "null" следует избегать."</div> </dd> </dl> @@ -51,11 +51,11 @@ Access-Control-Allow-Origin: null <pre class="notranslate">Access-Control-Allow-Origin: https://developer.mozilla.org</pre> -<p>Чтобы ограничить <code>Access-Control-Allow-Origin</code> разрешенным набором значений, необходимо реализовать логику на стороне сервера для проверки значения заголовка {{HTTPHeader("Origin")}} запроса, спавнить его с разрешенным списком источников, а затем, если значение {{HTTPHeader("Origin")}} присутствует в списке, задать значение <code>Access-Control-Allow-Origin</code>, равное значению {{HTTPHeader("Origin")}}.</p> +<p>Чтобы ограничить <code>Access-Control-Allow-Origin</code> разрешенным набором значений, необходимо реализовать логику на стороне сервера для проверки значения заголовка {{HTTPHeader("Origin")}} запроса, сравнить его с разрешенным списком источников, а затем, если значение {{HTTPHeader("Origin")}} присутствует в списке, задать значение <code>Access-Control-Allow-Origin</code>, равное значению {{HTTPHeader("Origin")}}.</p> <h3 id="CORS_и_кэширование">CORS и кэширование</h3> -<p>Если сервер послал ответ со значением <code>Access-Control-Allow-Origin</code>, которое содержит явное указание источника (а не шаблонное значние "<code>*</code>"), тогда ответ также должен включать в себя заголовок {{HTTPHeader("Vary")}} со значением <code>Origin</code> — чтобы указать браузеру, что ответы с сервера могут отличаться в зависимости от заголовка запроса <code>Origin</code>.</p> +<p>Если сервер послал ответ со значением <code>Access-Control-Allow-Origin</code>, которое содержит явное указание источника (а не шаблонное значение "<code>*</code>"), тогда ответ также должен включать в себя заголовок {{HTTPHeader("Vary")}} со значением <code>Origin</code> — чтобы указать браузеру, что ответы с сервера могут отличаться в зависимости от заголовка запроса <code>Origin</code>.</p> <pre class="notranslate">Access-Control-Allow-Origin: https://developer.mozilla.org Vary: Origin</pre> diff --git a/files/ru/web/http/headers/cache-control/index.html b/files/ru/web/http/headers/cache-control/index.html index f30d5debcf..4d1165c324 100644 --- a/files/ru/web/http/headers/cache-control/index.html +++ b/files/ru/web/http/headers/cache-control/index.html @@ -91,7 +91,7 @@ Cache-Control: stale-if-error=<seconds> <dt><code>s-maxage=<seconds></code></dt> <dd>Переопределяет <code>max-age</code> или заголовок <code>Expires</code>, но применяется только для разделяемых кэшей (например, прокси) и игнорируется частными кэшами.</dd> <dt><code>max-stale[=<seconds>]</code></dt> - <dd>Указывает, что клиент хочет пролучить ответ, для которого было превышено время устаревания. Дополнительно может быть указано значение в секундах, указывающее, что ответ не должен быть просрочен более чем на указанное значение.</dd> + <dd>Указывает, что клиент хочет получить ответ, для которого было превышено время устаревания. Дополнительно может быть указано значение в секундах, указывающее, что ответ не должен быть просрочен более чем на указанное значение.</dd> <dt><code>min-fresh=<seconds></code></dt> <dd>Указывает, что клиент хочет получить ответ, который будет актуален как минимум указанное количество секунд.</dd> <dt><code>stale-while-revalidate=<seconds></code> {{experimental_inline}}</dt> diff --git a/files/ru/web/http/headers/content-disposition/index.html b/files/ru/web/http/headers/content-disposition/index.html index 7004a28735..144fb4b808 100644 --- a/files/ru/web/http/headers/content-disposition/index.html +++ b/files/ru/web/http/headers/content-disposition/index.html @@ -10,7 +10,7 @@ original_slug: Web/HTTP/Заголовки/Content-Disposition --- <div>{{HTTPSidebar}}</div> -<div>В обычном HTTP-ответе заголовок <code><strong>Content-Disposition</strong></code> является индикатором того, что ожидаемый контент ответа будет отображаться в браузере, как вэб-страница или часть вэб-страницы, или же как вложение, которое затем может быть скачано и сохранено локально.</div> +<div>В обычном HTTP-ответе заголовок <code><strong>Content-Disposition</strong></code> является индикатором того, что ожидаемый контент ответа будет отображаться в браузере, как веб-страница или часть веб-страницы, или же как вложение, которое затем может быть скачано и сохранено локально.</div> <div> </div> @@ -36,7 +36,7 @@ original_slug: Web/HTTP/Заголовки/Content-Disposition <h3 id="Как_заголовок_ответа_с_обычным_телом">Как заголовок ответа с обычным телом</h3> -<p>Первым параметром в контексте HTTP должен быть или <code>inline</code> (это значение по умолчанию, указывающее, что контент должен быть отображен внутри вэб-страницы или как вэб-страница) или <code>attachment</code> (указывает на скачиваемый контент; большинство браузеров отображают диалог "Сохранить как" с заранее заполненным именем файла из параметра <code>filename</code>, если он задан).</p> +<p>Первым параметром в контексте HTTP должен быть или <code>inline</code> (это значение по умолчанию, указывающее, что контент должен быть отображен внутри веб-страницы или как веб-страница) или <code>attachment</code> (указывает на скачиваемый контент; большинство браузеров отображают диалог "Сохранить как" с заранее заполненным именем файла из параметра <code>filename</code>, если он задан).</p> <pre class="syntaxbox">Content-Disposition: inline Content-Disposition: attachment diff --git a/files/ru/web/http/headers/content-language/index.html b/files/ru/web/http/headers/content-language/index.html index 82099fc680..bf273885a3 100644 --- a/files/ru/web/http/headers/content-language/index.html +++ b/files/ru/web/http/headers/content-language/index.html @@ -58,7 +58,7 @@ Content-Language: de-DE, en-CA <h3 id="Указание_использованного_языка_документа">Указание использованного языка документа</h3> -<p>Глобальный аттрибут <code><a href="/en-US/docs/Web/HTML/Global_attributes/lang">lang</a></code> используется на HTML элементах для указания языка всего HTML документа или его частей.</p> +<p>Глобальный атрибут <code><a href="/en-US/docs/Web/HTML/Global_attributes/lang">lang</a></code> используется на HTML элементах для указания языка всего HTML документа или его частей.</p> <pre class="brush: html"><html lang="de"></pre> diff --git a/files/ru/web/http/headers/content-length/index.html b/files/ru/web/http/headers/content-length/index.html index 8212fa93f4..baefce6314 100644 --- a/files/ru/web/http/headers/content-length/index.html +++ b/files/ru/web/http/headers/content-length/index.html @@ -57,7 +57,7 @@ original_slug: Web/HTTP/Заголовки/Content-Length <h2 id="Браузерная_совместимость">Браузерная совместимость</h2> -<p class="hidden">Таблица совместимостина этой странице сгенерирована из структурированных данных. Если вы хотите добавить данные, пожалуйста отправьте пулл-реквест в репозиторий <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a></p> +<p class="hidden">Таблица совместимости на этой странице сгенерирована из структурированных данных. Если вы хотите добавить данные, пожалуйста отправьте пул-реквест в репозиторий <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a></p> <p>{{Compat("http.headers.Content-Length")}}</p> diff --git a/files/ru/web/http/headers/dnt/index.html b/files/ru/web/http/headers/dnt/index.html index 8b6be230e0..c4b7d6ae4d 100644 --- a/files/ru/web/http/headers/dnt/index.html +++ b/files/ru/web/http/headers/dnt/index.html @@ -33,14 +33,14 @@ DNT: 1 <dt>0</dt> <dd>Пользователь разрешает отслеживание на целевом сайте.</dd> <dt>1</dt> - <dd>Пользователь предпочитает не остлеживаться на целевом сайте.</dd> + <dd>Пользователь предпочитает не отслеживаться на целевом сайте.</dd> </dl> <h2 id="Примеры">Примеры</h2> <h3 id="Чтение_статуса_Do_Not_Track_из_JavaScript">Чтение статуса Do Not Track из JavaScript</h3> -<p>DNT предпочтение пользвователя может быть считано из JavaScript используя свойство {{domxref("Navigator.doNotTrack")}} :</p> +<p>DNT предпочтение пользователя может быть считано из JavaScript используя свойство {{domxref("Navigator.doNotTrack")}} :</p> <pre class="brush: js">navigator.doNotTrack; // "0" or "1"</pre> diff --git a/files/ru/web/http/headers/etag/index.html b/files/ru/web/http/headers/etag/index.html index e8ab0a5f76..01aed7fa9b 100644 --- a/files/ru/web/http/headers/etag/index.html +++ b/files/ru/web/http/headers/etag/index.html @@ -35,7 +35,7 @@ ETag: "<etag_value>" <dt><code>W/</code> {{optional_inline}}</dt> <dd><code>'W/'</code> (чувствителен к регистру) указывает, что используется <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests#Weak_validation">слабый валидатор</a>. Слабые валидаторы легко сгенерировать, но они намного реже используются для сравнения. Сильные валидаторы идеальны для сравнения, но их может быть очень сложно сгенерировать эффективно. Слабое значение <code>Etag</code> двух представлений одного и того же ресурса может быть семантически одинаково, но не байт-в-байт.</dd> <dt>"<etag_value>"</dt> - <dd>Тэг сущности, уникально представляющий запрашиваемый ресурс. Это строка ASCII кодов, заключенная в двойные кавычки (например, <code>"675af34563dc-tr34"</code>). Метод, по которому генерируются значения <code>ETag</code>, не определен. Обычно, используется хэш контента, хэш последнего времени модификации или просто номер ревизии. Например, MDN использует шестнадцатиричных хэш wiki-содержимого.</dd> + <dd>Тэг сущности, уникально представляющий запрашиваемый ресурс. Это строка ASCII кодов, заключенная в двойные кавычки (например, <code>"675af34563dc-tr34"</code>). Метод, по которому генерируются значения <code>ETag</code>, не определен. Обычно, используется хэш контента, хэш последнего времени модификации или просто номер ревизии. Например, MDN использует шестнадцатеричных хэш wiki-содержимого.</dd> </dl> <h2 id="Примеры">Примеры</h2> @@ -47,17 +47,17 @@ ETag: W/"0815"</pre> <p>С помощью заголовков <code>ETag</code> и {{HTTPHeader("If-Match")}}, существует возможность обнаружить коллизии в процессе работы приложения.</p> -<p>Например, при редактировании MDN, текущее содержимое статьи захэшировано и помещено в ответ при помощи заголовока <code>Etag</code>:</p> +<p>Например, при редактировании MDN, текущее содержимое статьи захэшировано и помещено в ответ при помощи заголовка <code>Etag</code>:</p> <pre>ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre> -<p>При сохранении изменений в статье (данные отправляются), {{HTTPMethod("POST")}} запрос будет содержать заголовок {{HTTPHeader("If-Match")}}, значение которого эквивалетно значению <code>ETag</code>. Это позволяет проверить актуальность данных.</p> +<p>При сохранении изменений в статье (данные отправляются), {{HTTPMethod("POST")}} запрос будет содержать заголовок {{HTTPHeader("If-Match")}}, значение которого эквивалентно значению <code>ETag</code>. Это позволяет проверить актуальность данных.</p> <pre>If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"</pre> <p>Если хэши из заголовков не совпадают, это означает что данные уже были изменены между запросами (in-between) и будет возвращена ошибка {{HTTPStatus("412")}} <code>Precondition Failed</code>.</p> -<h3 id="Кэширование_неизменямых_ресурсов">Кэширование неизменямых ресурсов</h3> +<h3 id="Кэширование_неизменяемых_ресурсов">Кэширование неизменяемых ресурсов</h3> <p>Другая типичная ситуация для использования <code>ETag</code> — кэширование ресурсов, которые не будут изменяться. Если пользователь повторно посещает URL-адрес (с установленным заголовком <code>ETag</code>), и при этом данные слишком устарели и не могут быть использованы, тогда клиент отправит значение <code>ETag</code> внутри заголовка {{HTTPHeader("If-None-Match")}}:</p> diff --git a/files/ru/web/http/headers/if-match/index.html b/files/ru/web/http/headers/if-match/index.html index f09d5894b5..1f46b5bbb1 100644 --- a/files/ru/web/http/headers/if-match/index.html +++ b/files/ru/web/http/headers/if-match/index.html @@ -59,7 +59,7 @@ If-Match: * <table class="standard-table"> <tbody> <tr> - <th scope="col">Спецификвция</th> + <th scope="col">Спецификация</th> <th scope="col">Название</th> </tr> <tr> diff --git a/files/ru/web/http/headers/if-modified-since/index.html b/files/ru/web/http/headers/if-modified-since/index.html index e08d9e88b9..574931193f 100644 --- a/files/ru/web/http/headers/if-modified-since/index.html +++ b/files/ru/web/http/headers/if-modified-since/index.html @@ -80,7 +80,7 @@ original_slug: Web/HTTP/Заголовки/If-Modified-Since <h2 id="Совместимость_с_браузером">Совместимость с браузером</h2> -<p class="hidden">Таблица совместимости на этой страницы была сгенерирована из структурированных данных. Если вы хотите внести свой вклад в эти данные, то можете склонировать соответствующий репозиторий <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> и прислать нам пулл-реквест.</p> +<p class="hidden">Таблица совместимости на этой страницы была сгенерирована из структурированных данных. Если вы хотите внести свой вклад в эти данные, то можете склонировать соответствующий репозиторий <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> и прислать нам пул-реквест.</p> <p>{{Compat("http/headers/if-modified-since")}}</p> diff --git a/files/ru/web/http/headers/index.html b/files/ru/web/http/headers/index.html index 9cfb918eab..ddb86dab64 100644 --- a/files/ru/web/http/headers/index.html +++ b/files/ru/web/http/headers/index.html @@ -9,7 +9,7 @@ original_slug: Web/HTTP/Заголовки --- <p>{{ HTTPSidebar }}</p> -<p><span class="seoSummary"><strong>Заголовки HTTP </strong>позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (<code>:</code>) непостредственно значение.</span> <a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/Whitespace">Пробелы</a> перед значением игнорируются.</p> +<p><span class="seoSummary"><strong>Заголовки HTTP </strong>позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (<code>:</code>) непосредственно значение.</span> <a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/Whitespace">Пробелы</a> перед значением игнорируются.</p> <p><span class="tlid-translation translation" lang="ru"><span title="">Пользовательские собственные заголовки исторически использовались с префиксом X, но это соглашение было объявлено устаревшим в июне 2012 года из-за неудобств, вызванных тем, что нестандартные поля стали стандартом в </span></span> <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a><span class="tlid-translation translation" lang="ru"><span title="">;</span> <span title="">другие перечислены в реестре <a href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA</a>, исходное содержимое которого было определено в </span></span> <a class="external external-icon" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>.<span class="tlid-translation translation" lang="ru"><span title=""> IANA также поддерживает <a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml">реестр предлагаемых новых заголовков HTTP</a>.</span></span></p> @@ -96,7 +96,7 @@ original_slug: Web/HTTP/Заголовки </tr> <tr> <td><code><a href="/en-US/docs/Web/HTTP/Content_negotiation#The_Accept-Encoding.3a_header" title="https://developer.mozilla.org/en/HTTP/Content_negotiation#The_Accept-Encoding.3a_header">Accept-Encoding</a></code></td> - <td>Спиcок форматов сжатия данных, которые поддерживает клиент.</td> + <td>Список форматов сжатия данных, которые поддерживает клиент.</td> <td><a href="/ru/docs/Web/HTTP/Content_negotiation" title="ru/HTTP/Content negotiation">HTTP Content Negotiation</a></td> <td>HTTP/1.1</td> </tr> diff --git a/files/ru/web/http/headers/origin/index.html b/files/ru/web/http/headers/origin/index.html index 1f4673dce4..d5bc3fa8ea 100644 --- a/files/ru/web/http/headers/origin/index.html +++ b/files/ru/web/http/headers/origin/index.html @@ -37,7 +37,7 @@ Origin: <протокол> "://" <имя_хоста> [ ":" <по <dt><имя_хоста></dt> <dd>Доменное имя сервера (для виртуального хостинга) или IP.</dd> <dt><порт> {{optional_inline}}</dt> - <dd>Номер TCP порта, который сервер будет слушать. Если порт не задан, будет использован порт по умолчанию для указаного сервиса (например "80" для HTTP).</dd> + <dd>Номер TCP порта, который сервер будет слушать. Если порт не задан, будет использован порт по умолчанию для указанного сервиса (например "80" для HTTP).</dd> </dl> <h2 id="Примеры">Примеры</h2> diff --git a/files/ru/web/http/headers/set-cookie/index.html b/files/ru/web/http/headers/set-cookie/index.html index 96b2086206..1898f6cf56 100644 --- a/files/ru/web/http/headers/set-cookie/index.html +++ b/files/ru/web/http/headers/set-cookie/index.html @@ -62,8 +62,8 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> <dt><code><cookie-name>=<cookie-value></code></dt> <dd>Cookie начинается с пары имя-значение: <ul> - <li><code><cookie-name></code> может содержать любые символы US-ASCII, за исключением управляющих символов (CTLs), пробелов, или табуляций. Оно также не должно содержать разделительнных символов, таких как следующие: <code>( ) < > @ , ; : \ " / [ ] ? = { }</code>.</li> - <li><code><cookie-value></code> может быть опционально заключено в двойные кавычки, разрешены любые символы US-ASCII за исключением CTLs, пробела, двойных кавычек, запятой, точки с запятой, и обратного слэша. <strong>Кодирование:</strong> Многие реализации выполняют кодирование в значениях cookies, однако этого не требуется по спецификации RFC. Однако, это помогает удовлетворить требование о разрешенных символах в <cookie-value>.</li> + <li><code><cookie-name></code> может содержать любые символы US-ASCII, за исключением управляющих символов (CTLs), пробелов, или табуляций. Оно также не должно содержать разделительных символов, таких как следующие: <code>( ) < > @ , ; : \ " / [ ] ? = { }</code>.</li> + <li><code><cookie-value></code> может быть опционально заключено в двойные кавычки, разрешены любые символы US-ASCII за исключением CTLs, пробела, двойных кавычек, запятой, точки с запятой, и обратного слеша. <strong>Кодирование:</strong> Многие реализации выполняют кодирование в значениях cookies, однако этого не требуется по спецификации RFC. Однако, это помогает удовлетворить требование о разрешенных символах в <cookie-value>.</li> <li><strong><code>__Secure-</code> prefix</strong> {{non-standard_inline}}: Cookies с именем, начинающимся с <code> __Secure-</code> (подчеркивание является частью префикса ) должны быть установлены вместе с флагом secure, и должны быть с безопасной страницы (HTTPS).</li> <li><strong><code>__Host-</code> prefix</strong> {{non-standard_inline}}: Cookies с именем, начинающимся с <code>__Host-</code> должны быть установлены с флагом secure <code>secure</code>, должны быть с безопасной страницы (HTTPS), не должны иметь определенный домен (и, следовательно, не не посылаются поддоменами), а также параметр Path должен быть "/".</li> </ul> @@ -72,7 +72,7 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> <dd> <p>Максимальное время жизни cookie в формате метки даты-времени HTTP. См. {{HTTPHeader("Date")}} о деталях формата Если не определен, cookie будет иметь время жизни <strong>сессионного cookie. </strong>Сессия окончена, когда клиент отключается, что приводит к удалению сессионных cookie в этот момент. Однако, многие браузеры имеют возможность, называемую восстановление сессии, которая сохраняет все ваши вкладки и затем возвращает их, когда вы в следующий раз запускаете браузер. Cookies будут также присутствовать, словно вы никогда не закрывали браузер.</p> - <p>Когда установливается срок действия, время и дата устанавливаются не относитеьно сервера, а относительно клиента, на котором установлено cookie,</p> + <p>Когда устанавливается срок действия, время и дата устанавливаются не относительно сервера, а относительно клиента, на котором установлено cookie,</p> </dd> <dt><code>Max-Age=<number> </code>{{optional_inline}}</dt> <dd>Количество секунд, после которого cookie устаревает. Ноль или отрицательное число приводят к моментальному устареванию cookie. Старые браузеры (ie6, ie7, and ie8) не поддерживают Max-Age. Для прочих браузеров, если оба параметра (<code>Expires</code> and <code>Max-Age</code>) установлены, <code>Max-Age</code> будет иметь преимущество.</dd> @@ -90,13 +90,13 @@ Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> <dt><code>Secure</code> {{optional_inline}}</dt> <dd>Cookie будет отправлен на сервер только с запросами c использованием SSL и протокола HTTPS.<br> <br> - Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную инфомрацию.</dd> + Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную информацию.</dd> <dd> <p><strong>Note:</strong> небезопасные сайты (<code>http:</code>) не могут использовать cookie с атрибутом "secure" (начиная с Chrome 52+ и Firefox 52+).</p> </dd> <dt><code>HttpOnly</code> {{optional_inline}}</dt> <dd>Запрещает JavaScript доступ к cookie</dd> - <dd>Полезно для защиы от XSS-атак.</dd> + <dd>Полезно для защиты от XSS-атак.</dd> <dt><code>SameSite=<samesite-value></code> {{optional_inline}}</dt> </dl> diff --git a/files/ru/web/http/headers/strict-transport-security/index.html b/files/ru/web/http/headers/strict-transport-security/index.html index 14e7b9e19d..b4c6271a82 100644 --- a/files/ru/web/http/headers/strict-transport-security/index.html +++ b/files/ru/web/http/headers/strict-transport-security/index.html @@ -72,7 +72,7 @@ Strict-Transport-Security: max-age=<expire-time>; preload <h2 id="Пример">Пример</h2> -<p>Все текущие и будущие сабдомены будут HTTPS по max-age на 1 год. Это блокирует доступ к страницам или сабдоменам, которые могут быть доступны только по HTTP.</p> +<p>Все текущие и будущие субдомены будут HTTPS по max-age на 1 год. Это блокирует доступ к страницам или субдоменам, которые могут быть доступны только по HTTP.</p> <pre class="notranslate">Strict-Transport-Security: max-age=31536000; includeSubDomains</pre> diff --git a/files/ru/web/http/headers/x-forwarded-for/index.html b/files/ru/web/http/headers/x-forwarded-for/index.html index 47612909ad..337bdaaacd 100644 --- a/files/ru/web/http/headers/x-forwarded-for/index.html +++ b/files/ru/web/http/headers/x-forwarded-for/index.html @@ -59,7 +59,7 @@ X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178 <pre># Used for some Google services X-ProxyUser-Ip: 203.0.113.19</pre> -<h2 id="Спецификаци">Спецификаци</h2> +<h2 id="Спецификации">Спецификации</h2> <p>Не является частью любой текущей спецификации. Стандартизованная версия этого заголовка {{HTTPHeader("Forwarded")}}.</p> diff --git a/files/ru/web/http/headers/x-xss-protection/index.html b/files/ru/web/http/headers/x-xss-protection/index.html index 4b318369f0..442fe6ab95 100644 --- a/files/ru/web/http/headers/x-xss-protection/index.html +++ b/files/ru/web/http/headers/x-xss-protection/index.html @@ -68,7 +68,7 @@ X-XSS-Protection: 1; report=<reporting-uri> <h2 id="Спецификации">Спецификации</h2> -<p>Не является частью каких-либо спецификай или черновиков.</p> +<p>Не является частью каких-либо специфика или черновиков.</p> <h2 id="Поддерживается_браузерами">Поддерживается браузерами</h2> diff --git a/files/ru/web/http/messages/index.html b/files/ru/web/http/messages/index.html index 0aa51b52a1..e41f8ceecf 100644 --- a/files/ru/web/http/messages/index.html +++ b/files/ru/web/http/messages/index.html @@ -3,7 +3,7 @@ title: Сообщения HTTP slug: Web/HTTP/Messages tags: - HTTP - - ВебМеханика + - Веб Механика - Руководство translation_of: Web/HTTP/Messages --- @@ -133,7 +133,7 @@ translation_of: Web/HTTP/Messages <ul> <li>Заголовки, в отличие от тел, не сжимаются.</li> <li>Заголовки, которые зачастую практически совпадают у идущих подряд сообщений, приходится передавать по отдельности.</li> - <li>Мультиплекстность невозможна. Приходится открывать соединение для каждого сообщения, а теплые (warm) соединеня TCP эффективнее холодных (cold).</li> + <li>Мультиплексность невозможна. Приходится открывать соединение для каждого сообщения, а теплые (warm) соединения TCP эффективнее холодных (cold).</li> </ul> <p>HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки. Несколько потоков можно объединять друг с другом - такой процесс называется мультиплексированием - что позволяет более эффективно использовать TCP-соединения.</p> diff --git a/files/ru/web/http/methods/options/index.html b/files/ru/web/http/methods/options/index.html index 7df81b0124..a6f1d95b77 100644 --- a/files/ru/web/http/methods/options/index.html +++ b/files/ru/web/http/methods/options/index.html @@ -9,7 +9,7 @@ translation_of: Web/HTTP/Methods/OPTIONS --- <div>{{HTTPSidebar}}</div> -<p><strong>HTTP-метод</strong><strong> <code>OPTIONS</code> </strong>используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый URL для обработки метода OPTIONS, или * (зведочку) чтобы указать весь сервер целиком.</p> +<p><strong>HTTP-метод</strong><strong> <code>OPTIONS</code> </strong>используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый URL для обработки метода OPTIONS, или * (звездочку) чтобы указать весь сервер целиком.</p> <table class="properties"> <tbody> @@ -50,7 +50,7 @@ OPTIONS * HTTP/1.1 <h3 id="Определение_разрешенных_сервером_методов_запроса">Определение разрешенных сервером методов запроса</h3> -<p>Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно возпользоваться curl направить OPTIONS запрос:</p> +<p>Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно воспользоваться curl направить OPTIONS запрос:</p> <pre>curl -X OPTIONS http://example.org -i</pre> diff --git a/files/ru/web/http/methods/put/index.html b/files/ru/web/http/methods/put/index.html index 5c89a7887c..c759172730 100644 --- a/files/ru/web/http/methods/put/index.html +++ b/files/ru/web/http/methods/put/index.html @@ -69,7 +69,7 @@ Content-length: 16 Content-Location: /new.html </pre> -<p>Если целевой ресур содержит отправляемую сущность и сущность была успешно мутирована (обновлена), в соответствии с прилагаемыми в теле запроса данными, то сервер должен отправить или {{HTTPStatus("200")}} (<code>OK</code>), или {{HTTPStatus("204")}} (<code>No Content</code>) для информирования об успешном завершении запроса.</p> +<p>Если целевой ресурс содержит отправляемую сущность и сущность была успешно мутирована (обновлена), в соответствии с прилагаемыми в теле запроса данными, то сервер должен отправить или {{HTTPStatus("200")}} (<code>OK</code>), или {{HTTPStatus("204")}} (<code>No Content</code>) для информирования об успешном завершении запроса.</p> <pre>HTTP/1.1 204 No Content Content-Location: /existing.html diff --git a/files/ru/web/http/overview/index.html b/files/ru/web/http/overview/index.html index 86ea95db81..e4b79afce4 100644 --- a/files/ru/web/http/overview/index.html +++ b/files/ru/web/http/overview/index.html @@ -34,7 +34,7 @@ translation_of: Web/HTTP/Overview <p>Браузер <strong>всегда</strong> является той сущностью, которая создаёт запрос. Сервер обычно этого не делает, хотя за многие годы существования сети были придуманы способы, которые могут позволить выполнить запросы со стороны сервера.</p> -<p>Чтобы отобразить веб страницу, браузер отправляет начальный запрос для получения HTML-документа этой страницы. После этого браузер изучает этот документ, и запрашивает дополнительные файлы, необходимые для отбражения содержания веб-страницы (исполняемые скрипты, информацию о макете страницы - CSS таблицы стилей, дополнительные ресурсы в виде изображений и видео-файлов), которые непосредственно являются частью исходного документа, но расположены в других местах сети. Далее браузер соединяет все эти ресурсы для отображения их пользователю в виде единого документа — веб-страницы. Скрипты, выполняемые самим браузером, могут получать по сети дополнительные ресурсы на последующих этапах обработки веб-страницы, и браузер соответствующим образом обновляет отображение этой страницы для пользователя.</p> +<p>Чтобы отобразить веб страницу, браузер отправляет начальный запрос для получения HTML-документа этой страницы. После этого браузер изучает этот документ, и запрашивает дополнительные файлы, необходимые для отображения содержания веб-страницы (исполняемые скрипты, информацию о макете страницы - CSS таблицы стилей, дополнительные ресурсы в виде изображений и видео-файлов), которые непосредственно являются частью исходного документа, но расположены в других местах сети. Далее браузер соединяет все эти ресурсы для отображения их пользователю в виде единого документа — веб-страницы. Скрипты, выполняемые самим браузером, могут получать по сети дополнительные ресурсы на последующих этапах обработки веб-страницы, и браузер соответствующим образом обновляет отображение этой страницы для пользователя.</p> <p>Веб-страница является гипертекстовым документом. Это означает, что некоторые части отображаемого текста являются ссылками, которые могут быть активированы (обычно нажатием кнопки мыши) с целью получения и соответственно отображения новой веб-страницы (переход по ссылке). Это позволяет пользователю "перемещаться" по страницам сети (Internet). Браузер преобразует эти гиперссылки в HTTP-запросы и в дальнейшем полученные HTTP-ответы отображает в понятном для пользователя виде.</p> @@ -42,7 +42,7 @@ translation_of: Web/HTTP/Overview <p>На другой стороне коммуникационного канала расположен сервер, который обслуживает (англ. <em>serve</em>) пользователя, предоставляя ему документы по запросу. С точки зрения конечного пользователя, сервер всегда является некой одной виртуальной машиной, полностью или частично генерирующей документ, хотя фактически он может быть группой серверов, между которыми балансируется нагрузка, то есть перераспределяются запросы различных пользователей, либо сложным программным обеспечением, опрашивающим другие компьютеры (такие как кэширующие серверы, серверы баз данных, серверы приложений электронной коммерции и другие).</p> -<p>Сервер не обязательно расположен на одной машине, и наоборот - несколько серверов могут быть расположены (хоститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея {{HTTPHeader("Host")}} заголовок, они даже могут делить тот же самый IP-адрес.</p> +<p>Сервер не обязательно расположен на одной машине, и наоборот - несколько серверов могут быть расположены (поститься) на одной и той же машине. В соответствии с версией HTTP/1.1 и имея {{HTTPHeader("Host")}} заголовок, они даже могут делить тот же самый IP-адрес.</p> <h3 id="Прокси">Прокси</h3> @@ -76,9 +76,9 @@ translation_of: Web/HTTP/Overview <p>HTTP/1.0 открывал TCP-соединение для каждого обмена запросом/ответом, имея два важных недостатка: открытие соединения требует нескольких обменов сообщениями, и потому медленно, хотя становится более эффективным при отправке нескольких сообщений, или при регулярной отправке сообщений: <em>теплые</em> соединения более эффективны, чем <em>холодные</em>.</p> -<p>Для смягчения этих недостатков, HTTP/1.1 предоставил конвеерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок {{HTTPHeader("Connection")}}. HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным.</p> +<p>Для смягчения этих недостатков, HTTP/1.1 предоставил конвейерную обработку (которую оказалось трудно реализовать) и устойчивые соединения: лежащее в основе TCP соединение можно частично контролировать через заголовок {{HTTPHeader("Connection")}}. HTTP/2 сделал следующий шаг, добавив мультиплексирование сообщений через простое соединение, помогающее держать соединение теплым и более эффективным.</p> -<p>Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google эксперементирует с <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>, которая основана на UDP, для предоставления более надёжного и эффективного транспортного протокола.</p> +<p>Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google экспериментирует с <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>, которая основана на UDP, для предоставления более надёжного и эффективного транспортного протокола.</p> <h2 id="Чем_можно_управлять_через_HTTP">Чем можно управлять через HTTP</h2> @@ -90,10 +90,10 @@ translation_of: Web/HTTP/Overview <li><em><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching">Кэш</a></em><br> Сервер может инструктировать прокси и клиенты: что и как долго кэшировать. Клиент может инструктировать прокси промежуточных кэшей игнорировать хранимые документы.</li> <li><em>Ослабление ограничений источника</em><br> - Для предотвращения шпионских и других, нарушающих приватность, вторжений, веб-браузер обчеспечивает строгое разделение между веб-сайтами. Только страницы из<strong> того же источника</strong> могут получить доступ к информации на веб-странице. Хотя такие ограничение нагружают сервер, заголовки HTTP могут ослабить строгое разделение на стороне сервера, позволяя документу стать частью информации с различных доменов (по причинам безопасности).</li> + Для предотвращения шпионских и других, нарушающих приватность, вторжений, веб-браузер обеспечивает строгое разделение между веб-сайтами. Только страницы из<strong> того же источника</strong> могут получить доступ к информации на веб-странице. Хотя такие ограничение нагружают сервер, заголовки HTTP могут ослабить строгое разделение на стороне сервера, позволяя документу стать частью информации с различных доменов (по причинам безопасности).</li> <li><em>Аутентификация</em><br> Некоторые страницы доступны только специальным пользователям. Базовая аутентификация может предоставляться через HTTP, либо через использование заголовка {{HTTPHeader("WWW-Authenticate")}} и подобных ему, либо с помощью настройки спецсессии, используя куки.</li> - <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Прокси и тунелирование</a></em><br> + <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Прокси и туннелирование</a></em><br> Серверы и/или клиенты часто располагаются в интернете, и скрывают свои истинные IP-адреса от других. HTTP запросы идут через прокси для пересечения этого сетевого барьера. Не все прокси -- HTTP прокси. SOCKS-протокол, например, оперирует на более низком уровне. Другие, как, например, ftp, могут быть обработаны этими прокси.</li> <li><em>Сессии</em><br> Использование HTTP кук позволяет связать запрос с состоянием на сервере. Это создает сессию, хотя ядро HTTP -- протокол без состояния. Это полезно не только для корзин в интернет-магазинах, но также для любых сайтов, позволяющих пользователю настроить выход.</li> @@ -104,8 +104,8 @@ translation_of: Web/HTTP/Overview <p>Когда клиент хочет взаимодействовать с сервером, являясь конечным сервером или промежуточным прокси, он выполняет следующие шаги:</p> <ol> - <li>Открытие TCP соединения: TCP-соедиенение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.</li> - <li>Отправка HTTP-сообщения: HTTP-собщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсилуруются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. + <li>Открытие TCP соединения: TCP-соединение будет использоваться для отправки запроса или запросов, и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее, или открыть несколько TCP-соединений к серверу.</li> + <li>Отправка HTTP-сообщения: HTTP-сообщения (до HTTP/2) -- человеко-читаемо. Начиная с HTTP/2, простые сообщения инкапсулируются во фреймы, делая невозможным их чтения напрямую, но принципиально остаются такими же. <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr</code></pre> @@ -125,7 +125,7 @@ Content-Type: text/html <li>Закрывает или переиспользует соединение для дальнейших запросов.</li> </ol> -<p>Если активирован HTTP-конвеер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвеер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями. HTTP-конвеер был заменен в HTTP/2 на более надежные мультиплексные запросы во фрейме.</p> +<p>Если активирован HTTP-конвейер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвейер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями. HTTP-конвейер был заменен в HTTP/2 на более надежные мультиплексные запросы во фрейме.</p> <h2 id="HTTP_сообщения">HTTP сообщения</h2> @@ -145,7 +145,7 @@ Content-Type: text/html <li>HTTP-<a href="/en-US/docs/Web/HTTP/Methods">метод</a>, обычно глагол подобно {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} или существительное, как {{HTTPMethod("OPTIONS")}} или {{HTTPMethod("HEAD")}}, определяющее операцию, которую клиент хочет выполнить. Обычно, клиент хочет получить ресурс (используя <code>GET</code>) или передать значения <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML-формы</a> (используя <code>POST</code>), хотя другие операция могут быть необходимы в других случаях.</li> <li>Путь к ресурсу: URL ресурсы <span id="result_box" lang="ru"><span>лишены элементов, которые очевидны из контекста</span></span>, например без {{glossary("protocol")}} (<code>http://</code>), {{glossary("domain")}} (здесь <code>developer.mozilla.org</code>), или TCP {{glossary("port")}} (здесь <code>80</code>).</li> <li>Версию HTTP-протокола.</li> - <li><a href="/en-US/docs/Web/HTTP/Headers">Заголовки</a> (опционально), предоставляюшие дополнительную информацию для сервера.</li> + <li><a href="/en-US/docs/Web/HTTP/Headers">Заголовки</a> (опционально), предоставляющие дополнительную информацию для сервера.</li> <li>Или тело, для некоторых методов, таких как <code>POST</code>, которое содержит отправленный ресурс.</li> </ul> @@ -169,4 +169,4 @@ Content-Type: text/html <p>HTTP -- легкий в использовании расширяемый протокол. Структура клиент-сервера, вместе со способностью к простому добавлению заголовков, позволяет HTTP продвигаться вместе с расширяющимися возможностями Сети.</p> -<p>Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионый поток остается простым, позволяя исследовать и отлаживать с простым <a href="/en-US/docs/Tools/Network_Monitor">монитором HTTP-сообщений</a>.</p> +<p>Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP сообщения во фреймы для улучшения производительности, базовая структура сообщений осталась с HTTP/1.0. Сессионный поток остается простым, позволяя исследовать и отлаживать с простым <a href="/en-US/docs/Tools/Network_Monitor">монитором HTTP-сообщений</a>.</p> diff --git a/files/ru/web/http/redirections/index.html b/files/ru/web/http/redirections/index.html index 8a9c509b06..aa1a214099 100644 --- a/files/ru/web/http/redirections/index.html +++ b/files/ru/web/http/redirections/index.html @@ -70,7 +70,7 @@ translation_of: Web/HTTP/Redirections <td><code>Found</code></td> <td>{{HTTPMethod("GET")}} методы неизменны.<br> Другие методы <u>могут</u> быть превращены в {{HTTPMethod("GET")}}.<sup><a href="#attr2">[2]</a></sup></td> - <td>Веб-страница недоступна по непредвиденым причинам. В этом случае поисковые роботы не будут обновлять свои ссылки.</td> + <td>Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки.</td> </tr> <tr> <td><code>303</code></td> @@ -151,7 +151,7 @@ translation_of: Web/HTTP/Redirections <ol> <li>HTTP перенаправления всегда выполняются первыми, пока еще страница даже не была передана, и конечно же, пока еще не прочитана.</li> - <li>HTML перенаправления ({{HTMLElement("meta")}}) выполняються только, если перенаправление не было в выполнено в HTTP.</li> + <li>HTML перенаправления ({{HTMLElement("meta")}}) выполняются только, если перенаправление не было в выполнено в HTTP.</li> <li>JavaScript перенаправления используются как последняя возможность перенаправления, и работают только если разрешено выполнение JavaScript на клиентской стороне.</li> </ol> @@ -205,7 +205,7 @@ translation_of: Web/HTTP/Redirections </VirtualHost> </pre> -<p>URL <code>http://example.com/</code> будет переенаправлен к <code>http://www.example.com/</code> (но не к <code>http://example.com/other.html</code> )</p> +<p>URL <code>http://example.com/</code> будет перенаправлен к <code>http://www.example.com/</code> (но не к <code>http://example.com/other.html</code> )</p> <p><code>Redirect_Match</code> делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:</p> diff --git a/files/ru/web/http/status/103/index.html b/files/ru/web/http/status/103/index.html index d6c39cdb12..3ea9a231ea 100644 --- a/files/ru/web/http/status/103/index.html +++ b/files/ru/web/http/status/103/index.html @@ -6,7 +6,7 @@ tags: - Информация - Код состояния - ТаблицаСоответствия - - ТребуетсяСодержание + - Требуется Содержание - Черновик translation_of: Web/HTTP/Status/103 --- diff --git a/files/ru/web/http/status/402/index.html b/files/ru/web/http/status/402/index.html index e25ebef0f3..93b58f1dd6 100644 --- a/files/ru/web/http/status/402/index.html +++ b/files/ru/web/http/status/402/index.html @@ -7,7 +7,7 @@ translation_of: Web/HTTP/Status/402 <p>HTTP-ответ <strong><code>402 Payment Required</code></strong> это нестандартная ошибка клиента, зарезервированная для использования в будущем.</p> -<p>Иногда этот код означает, что запрос не может быть выполнен до тех пор, пока клиен не совершит оплату. Изначально создан для активации цифровых сретств или (микро) платежных систем и изображает, что запрошенный контент недоступен пока клиент не совершит оплату. Так или иначе, стандартизованного использования для кода нет, и он может использоваться разными элементами в разном контексте.</p> +<p>Иногда этот код означает, что запрос не может быть выполнен до тех пор, пока клиент не совершит оплату. Изначально создан для активации цифровых средств или (микро) платежных систем и изображает, что запрошенный контент недоступен пока клиент не совершит оплату. Так или иначе, стандартизованного использования для кода нет, и он может использоваться разными элементами в разном контексте.</p> <h2 id="Статус">Статус</h2> diff --git a/files/ru/web/http/status/403/index.html b/files/ru/web/http/status/403/index.html index 91222d7aef..42f95f5f95 100644 --- a/files/ru/web/http/status/403/index.html +++ b/files/ru/web/http/status/403/index.html @@ -36,7 +36,7 @@ Date: Wed, 21 Oct 2015 07:28:00 GMT <h2 id="Совместимость_с_браузером">Совместимость с браузером</h2> -<p class="hidden">Таблица совместимости на этой странице сгенерирована из структурированых данных. Если вы хотите внести вклад в содержимое, пожалуйста посетите <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> и отправьте нам запрос.</p> +<p class="hidden">Таблица совместимости на этой странице сгенерирована из структурированных данных. Если вы хотите внести вклад в содержимое, пожалуйста посетите <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> и отправьте нам запрос.</p> <p>{{Compat("http/status", "403")}}</p> diff --git a/files/ru/web/http/status/416/index.html b/files/ru/web/http/status/416/index.html index 05ffd0b379..d7035dfb3f 100644 --- a/files/ru/web/http/status/416/index.html +++ b/files/ru/web/http/status/416/index.html @@ -11,7 +11,7 @@ translation_of: Web/HTTP/Status/416 <p>Код ошибки HTTP <strong>416 Range Not Satisfiable</strong> указывает, что сервер не может обслуживать запрошенные диапазоны. Наиболее вероятная причина заключается в том, что документ не содержит таких диапазонов или что значение {{HTTPHeader ("Range")}}, хотя и синтаксически корректно, не имеет смысла.</p> -<p>Cообщение ответа 416 содержит {{HTTPHeader("Content-Range")}}, указывающий на неудовлетворенный диапазон (это <code>'*'</code>), за которым следуют <code>'/'</code> и текущий ресурс. Например: <code>Content-Range: */12777</code></p> +<p>Сообщение ответа 416 содержит {{HTTPHeader("Content-Range")}}, указывающий на неудовлетворенный диапазон (это <code>'*'</code>), за которым следуют <code>'/'</code> и текущий ресурс. Например: <code>Content-Range: */12777</code></p> <p>Столкнувшись с этой ошибкой, браузеры обычно либо прерывают операцию (например, загрузка будет считаться не возобновляемой), либо снова запрашиваются ведь документ.</p> diff --git a/files/ru/web/http/status/501/index.html b/files/ru/web/http/status/501/index.html index 4f13aabd5e..f781b3460e 100644 --- a/files/ru/web/http/status/501/index.html +++ b/files/ru/web/http/status/501/index.html @@ -4,7 +4,7 @@ slug: Web/HTTP/Status/501 translation_of: Web/HTTP/Status/501 --- <div> -<p>The HTTP <code><strong>501</strong></code><strong><code> Not Implemented</code></strong> cерверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются {{HTTPMethod("GET")}} и {{HTTPMethod("HEAD")}}.</p> +<p>The HTTP <code><strong>501</strong></code><strong><code> Not Implemented</code></strong> серверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются {{HTTPMethod("GET")}} и {{HTTPMethod("HEAD")}}.</p> <p>Обратите внимание, что 501 error не является чем-то, что вы можете исправить, но требует исправления веб-сервером, к которому вы пытаетесь получить доступ.</p> </div> diff --git a/files/ru/web/http/status/502/index.html b/files/ru/web/http/status/502/index.html index 0e1bccb304..0c90977db6 100644 --- a/files/ru/web/http/status/502/index.html +++ b/files/ru/web/http/status/502/index.html @@ -35,7 +35,7 @@ translation_of: Web/HTTP/Status/502 <h2 id="Совместимость_с_браузерами">Совместимость с браузерами</h2> -<p class="hidden">Эта таблица совместимости сгенерирована на основе структурированных данных. Если вы бы хотели сделать свой вклаж в данные, пожалуйста, посетите <a href="https://github.com/mdn/browser-compat-data/README.md">https://github.com/mdn/browser-compat-data/README.md</a> и отправьте нам pull request.</p> +<p class="hidden">Эта таблица совместимости сгенерирована на основе структурированных данных. Если вы бы хотели сделать свой вклад в данные, пожалуйста, посетите <a href="https://github.com/mdn/browser-compat-data/README.md">https://github.com/mdn/browser-compat-data/README.md</a> и отправьте нам pull request.</p> <p>{{Compat("http/status", "502")}}</p> diff --git a/files/ru/web/http/status/index.html b/files/ru/web/http/status/index.html index 4ca660ba38..ec06ff4477 100644 --- a/files/ru/web/http/status/index.html +++ b/files/ru/web/http/status/index.html @@ -25,7 +25,7 @@ translation_of: Web/HTTP/Status <p><font><font>Коды состояния определены в </font></font><a href="https://tools.ietf.org/html/rfc2616#section-10"><font><font>10-ой секции RFC 2616</font></font></a><font><font>. О</font><font>бновленную спецификацию можно найти в </font></font><a href="https://tools.ietf.org/html/rfc7231#section-6.5.1"><font><font>RFC 7231</font></font></a><font><font> . </font></font></p> -<p>Если Вы получли код ответа (состояния), которого нет в данном списке, в таком случае он является не стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.</p> +<p>Если Вы получили код ответа (состояния), которого нет в данном списке, в таком случае он является не стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.</p> <p>Следующая таблица содержит список всех кодов и их значения:</p> @@ -63,7 +63,7 @@ translation_of: Web/HTTP/Status <tr> <td>103</td> <td>Early Hints</td> - <td>"Ранние подсказки". В ответе сообщаются ресурсы, которые могут быть загружены заранее, пока сервер будет подготовливать основной ответ. <a href="https://datatracker.ietf.org/doc/rfc8297">RFC 8297 (Experimental)</a>.</td> + <td>"Ранние подсказки". В ответе сообщаются ресурсы, которые могут быть загружены заранее, пока сервер будет подготавливать основной ответ. <a href="https://datatracker.ietf.org/doc/rfc8297">RFC 8297 (Experimental)</a>.</td> <td>Только HTTP/1.1</td> </tr> <tr> @@ -199,7 +199,7 @@ translation_of: Web/HTTP/Status <tr> <td id="401">401</td> <td>Unauthorized</td> - <td>"Неавторизовано". Для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна. </td> + <td>"Неавторизованно". Для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна. </td> <td>HTTP/0.9 and later</td> </tr> <tr> @@ -243,7 +243,7 @@ translation_of: Web/HTTP/Status <tr> <td id="408">408</td> <td>Request Timeout</td> - <td>Ответ с таким кодом может прийти, даже без предшествующего запроса. Он означает, что сервер хотел бы отключить это неиспользуемое соеднинение. Этот метод используется все чаще с тех пор, как некоторые браузеры, вроде Chrome и IE9, стали использовать <a class="external" href="http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/" title="http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/">HTTP механизмы предварительного соединения</a> для ускорения серфинга (смотрите {{ bug(634278) }}, будущей реализации этого механизма в Firefox). Также учитывайте, что некоторые серверы прерывают соединения не отправляя подобных сообщений.</td> + <td>Ответ с таким кодом может прийти, даже без предшествующего запроса. Он означает, что сервер хотел бы отключить это неиспользуемое соединение. Этот метод используется все чаще с тех пор, как некоторые браузеры, вроде Chrome и IE9, стали использовать <a class="external" href="http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/" title="http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/">HTTP механизмы предварительного соединения</a> для ускорения серфинга (смотрите {{ bug(634278) }}, будущей реализации этого механизма в Firefox). Также учитывайте, что некоторые серверы прерывают соединения не отправляя подобных сообщений.</td> <td>HTTP/1.1 only</td> </tr> <tr> @@ -299,7 +299,7 @@ translation_of: Web/HTTP/Status <tr> <td id="416">416</td> <td>Requested Range Not Satisfiable</td> - <td>Диапозон указанный заголовком запроса <code>Range</code> не может быть выполнен; возможно, он выходит за пределы переданного URI</td> + <td>Диапазон указанный заголовком запроса <code>Range</code> не может быть выполнен; возможно, он выходит за пределы переданного URI</td> <td>HTTP/1.1 only</td> </tr> <tr> @@ -344,7 +344,7 @@ translation_of: Web/HTTP/Status <tr> <td id="505">505</td> <td>HTTP Version Not Supported</td> - <td>"HTTP-версия не поддерживается". HTTP-версия, используемая в запроcе, не поддерживается сервером.</td> + <td>"HTTP-версия не поддерживается". HTTP-версия, используемая в запросе, не поддерживается сервером.</td> <td>HTTP/1.1 only</td> </tr> </tbody> |