Документации

Аннотация Унифицированный идентификатор ресурса (URI) — это компактная последовательность символов, которая идентифицирует абстрактный или физический ресурс. В этой спецификации определяется общий синтаксис URI и процесс разрешения ссылок URI, которые могут быть в относительной форме, а также рекомендации и соображения безопасности по использованию URI в Интернете. Синтаксис URI определяет грамматику, которая […]

  Статус этого меморандума (Декабрь 1994 года) Этот документ определяет протокол отслеживания стандартов Интернета для интернет-сообщества и требует обсуждения и предложений по улучшению. Пожалуйста, обратитесь к текущему изданию «Официальных стандартов интернет-протокола» (STD 1), чтобы узнать о состоянии стандартизации и статусе этого протокола. Распространение этой памятки не ограничено.   Резюме Этот […]

Параметр «host» используется для пересылки исходного значения поля заголовка «Host«. Это может быть использовано, например, исходным сервером, если обратный прокси-сервер перезаписывает поле заголовка «Host» на какое-то внутреннее имя хоста. Синтаксис значения «host» после возможного восстановления строки в кавычках ДОЛЖЕН соответствовать ABNF узла, описанному в Разделе 5.4 [RFC7230 #].   Подробную […]

Параметр «proto» имеет значение используемого типа протокола. Синтаксис значения «proto» после возможного восстановления строки в кавычках ДОЛЖЕН соответствовать имени схемы URI, как определено в разделе 3.1 в [RFC3986 #] и зарегистрирован в IANA в соответствии с [RFC4395 #]. Типичными значениями являются «http» или «https«. Например, в среде, где обратный прокси-сервер […]

Параметр «by» используется для раскрытия интерфейса, через который поступил запрос на прокси-сервер. Когда прокси выбирают использование параметра «by«, его конфигурация по умолчанию ДОЛЖНА содержать «запутанный» идентификатор, как описано в [RFC 7239 Раздел 6.3]. Если серверу, получающему проксированные запросы, требуются некоторые функции на основе адреса, этот параметр МОЖЕТ вместо этого содержать […]

Параметр «for» используется для раскрытия информации о клиенте, инициировавшем запрос, и последующих прокси в цепочке прокси. Когда прокси выбирают использование параметра «for«, его конфигурация по умолчанию ДОЛЖНА содержать «запутанный» идентификатор, как описано в [RFC 7239 Раздел 6.3]. Если серверу, получающему проксированные запросы, требуются некоторые функции на основе адреса, этот параметр […]

Введение Этот документ определяет поле заголовка расширения HTTP, которое позволяет компонентам прокси раскрывать информацию, потерянную в процессе проксирования, например, исходный IP-адрес запроса или IP-адрес прокси-сервера в интерфейсе, обращённом к агенту пользователя. В пути проксирования компонентов это позволяет организовать его так, чтобы каждый последующий компонент имел доступ, например, ко всем IP-адресам, […]

Версия документа от 07 ноября 2021 года. Может измениться в будущем.   Входными данными для выборки является запрос (request). С запросом связан метод (method). Если не указано иное, это `GET`. Примечание Это может быть обновлено во время перенаправления на `GET`, как описано в HTTP-выборке. С запросом связан URL (URL). Примечание […]

Версия документа от 07 ноября 2021 года. Может измениться в будущем.   Результатом выборки является ответ (response). Ответ со временем развивается. То есть не все его поля доступны сразу. Ответ имеет связанный тип (type): «basic«, «cors«, «default«, «error«, «opaque» или «opaqueredirect«. Если не указано иное, это «default«. С ответом может […]

Аннотация Этот документ определяет понятие «origin» (происхождение/источник), которое часто используется в качестве области оснований или привилегий пользовательскими агентами. Обычно пользовательские агенты изолируют контент, полученный из разных источников, чтобы предотвратить вмешательство операторов вредоносных веб-сайтов в работу безопасных веб-сайтов. В дополнение к изложению принципов, лежащих в основе концепции происхождения, в этом документе […]

Оглавление 1. Аннотация 2. Описание 3. Синтаксис 4. Примеры 5. История 6. Безопасность 7. Ссылки Автор   1. Аннотация Определяется новая схема URL, «data«. Это позволяет включать небольшие элементы данных как «немедленные» (immediate) данные, как если бы они были включены извне. Оригинальная версия документа на английском языке RFC 2397 PDF […]

Аннотация В этом документе регистрируются схемы проверки подлинности по протоколу гипертекстовой передачи (HTTP), которые были определены в RFC до создания реестра схем проверки подлинности HTTP IANA.   Оглавление 1. Введение 2. Вопросы безопасности 3. Соображения IANA 4. Нормативные ссылки 1. Введение В этом документе регистрируются схемы проверки подлинности по протоколу […]

Аннотация Этот документ определяет поля заголовка «Cookie» и «Set-Cookie» в протоколе HTTP . Эти поля заголовков могут использоваться серверами HTTP для хранения состояния (называемых «cookies» куки-файлами) в пользовательских агентах HTTP, что позволяет серверам поддерживать сеанс с сохранением состояния по протоколу HTTP, который в основном не содержит состояний. Хотя файлы cookie […]

Живой стандарт — Обновление 29 июня 2020 года Принять участие: GitHub whatwg/xhr (new issue, open issues) IRC: #whatwg on Freenode Фиксировать: GitHub whatwg/xhr/commits Snapshot as of this commit @xhrstandard Тесты: web-platform-tests xhr/ (ongoing work) Переводы (ненормативные): https://triple-underscore.github.io/XHR-ja.html   Аннотация Стандарт XMLHttpRequest определяет API-интерфейс, который предоставляет клиенту функциональные возможности по сценарию для передачи данных […]

Эта РЕКОМЕНДУЕМАЯ операция аналогична операции Print-Job (раздел 4.2.1 из RFC 8011, за исключением того, что в запросе Create-Job клиент не предоставляет данные Документа или какие-либо ссылки на данные Документа. Кроме того, Клиент не предоставляет никаких атрибутов операции «document-name«, «document-format«, «compression» или «document-natural-language«. За этой операцией следует одна или несколько операций […]

Эта ТРЕБУЕМАЯ операция аналогична операции Print-Job (Задание на печать) (раздел 4.2.1 из RFC 8011, за исключением того, что Клиент не предоставляет данные Документа, а Принтер не выделяет никаких ресурсов, т. е. он не создает новое задание. Эта операция используется только для проверки возможностей принтера по любым атрибутам, предоставленным клиентом в […]

Эта НЕОБЯЗАТЕЛЬНАЯ операция идентична операции Принтера Print-Job (раздел 4.2.1 из RFC 8011, за исключением того, что Клиент (Client) предоставляет ссылку URI на данные Документа, используя атрибут операции «document-uri» (uri) (в Группе 1), а не включает Данные самого Документа. Перед возвратом ответа Принтер ДОЛЖЕН проверить, что Принтер поддерживает метод поиска (например, […]

Операция Принтера Print-Job (Задание на печать) — это ТРЕБУЕМАЯ операция, которая позволяет Клиенту (Client) отправить задание на печать (Print Job) только с одним документом (Document) и предоставить данные документа (Document data) (а не просто ссылку на данные). В Приложении C из RFC 8011 приведены предлагаемые шаги для обработки запросов на […]

Все операции Принтера (Printer) направлены на Принтеры (Printers). Клиент (Client) ДОЛЖЕН всегда указывать атрибут операции «printer-uri«, чтобы определить правильную цель операции. Print-Job Print-URI Validate-Job Create-Job Get-Printer-Attributes Get-Jobs Pause-Printer Resume-Printer Purge-Jobs   Значение кода состояния Операция протокола IPP Описание Объект IPP Определено в RFC 8011 PJ Print-Job Задание на печать Принтер […]

Объекты IPP (принтеры (Printers), задания (Jobs) и т. д.) поддерживают операции. Операция состоит из запроса (request) и ответа (response). Когда Клиент (Client) связывается с Принтером (Printer) или его Заданиями (Jobs), Клиент (Client) при необходимости отправляет запрос операции на URI Принтера (Printer URI) и числовой идентификатор объекта. Операционные запросы и ответы […]

Коды состояний для операций в протоколе IPP 1.1 представляют собой аббревиатуры слов, которыми можно описать текущую операцию. Возможные варианты кодов состояний для операций перечислены в таблице.   Значение кода состояния Операция протокола IPP Описание Объект IPP Определено в RFC 8011 PJ Print-Job Задание на печать Принтер Раздел 4.2.1 PU Print-URI […]

Код состояния «server-error-multiple-document-jobs-not-supported» в IPP 1.1 информирует о том, что Объект IPP не поддерживает несколько документов на одно задание, и клиент попытался предоставить данные документа с помощью второй операции Send-Document или Send-URI. (раздел B.1.5.10 из RFC 8011)   Код состояния «server-error-multiple-document-jobs-not-supported» в IPP 1.1 относится к классу ответа операции Server […]

Код состояния «server-error-job-canceled» в IPP 1.1 информирует о том, что Задание было отменено оператором или системой, когда клиент передавал данные на принтер IPP. Если атрибут «job-id» (идентификатор задания) и атрибут «job-uri» (uri задания) были созданы, то они возвращаются в ответе Print-Job, Send-Document или Send-URI как обычно; в противном случае в […]

Код состояния «server-error-busy» в IPP 1.1 информирует о том, что Это временная ошибка, указывающая на то, что принтер слишком занят обработкой заданий и/или других запросов. Клиент ДОЛЖЕН повторить немодифицированный запрос еще раз в некоторый более поздний момент времени, ожидая, что условие временного занятости будет снято. (раздел B.1.5.8 из RFC 8011) […]

Код состояния «server-error-not-accepting-jobs» в IPP 1.1 информирует о том, что Это временная ошибка, указывающая на то, что Printer (Принтер) в настоящее время не принимает Jobs (Задания), потому что Администратор установил значение атрибута «printer-is-accepting-jobs» в значение «false» (ложь) (что выходит за рамки данного документа IPP/1.1.). (раздел B.1.5.7 из RFC 8011)   […]

Код состояния «server-error-temporary-error» в IPP 1.1 информирует о том, что Временная ошибка, такая как ошибка записи в буфере, переполнение памяти (то есть данные документа превышают память принтера) или состояние переполнения диска, происходит, когда принтер IPP обрабатывает операцию. Клиент МОЖЕТ повторить немодифицированный запрос еще раз в какой-то более поздний момент времени, […]

Код состояния «server-error-device-error» в IPP 1.1 информирует о том, что это Ошибка принтера, например застревание бумаги, возникает, когда объект IPP обрабатывает операцию печати (Print) или (send) отправки. Ответ содержит истинное состояние задания (значения атрибутов «job-state» (состояние-задания) и «job-state-reasons» (причины-состояния-задания)). Дополнительная информация может быть возвращена в ДОПОЛНИТЕЛЬНОМ значении атрибута «job-state-message» или […]

Код состояния «server-error-version-not-supported» в IPP 1.1 информирует о том, что Объект IPP не поддерживает или отказывается поддерживать версию IPP, указанную в качестве значения параметра операции «version-number» (номер версии) в запросе. Объект IPP указывает, что он не может или не желает завершить запрос, используя тот же основной и младший номер версии, который […]

Код состояния «server-error-service-unavailable» в IPP 1.1 информирует о том, что в настоящее время объект IPP не может обработать запрос из-за временной перегрузки или из-за обслуживания объекта IPP. Подразумевается, что это временное состояние, которое будет смягчено после некоторой задержки. Если известно, длительность задержки может быть указана в сообщении. Если задержка не указана, […]

Код состояния «server-error-operation-not-supported» в IPP 1.1 информирует о том, что Объект IPP не поддерживает функции, необходимые для выполнения запроса. Это соответствующий ответ, когда объект IPP не распознает операцию или не способен ее поддержать. Смотри раздел 4.1.6.1 и раздел 4.1.7 из RFC 8011. Код состояния определён в: (раздел B.1.5.2 из RFC […]

Код состояния «server-error-internal-error» в IPP 1.1 информирует о том, что Объект IPP обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос. Этот код состояния ошибки отличается от «server-error-temporary-error» тем, что он подразумевает более постоянный тип внутренней ошибки. Он также отличается от «server-error-device-error» тем, что предполагает непредвиденное состояние (в отличие от […]

«Ошибки сервера» (Server Error) значения кодов состояния в IPP 1.1 — этот класс «значений кода состояния» (status-code values) указывает на случаи, когда объект IPP знает, что он допустил ошибку или неспособен выполнить запрос. Объект IPP ДОЛЖЕН включать в себя сообщение, содержащее объяснение ситуации ошибки и того, является ли это временным или […]

Код состояния «client-error-document-access-error» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос «Print-URI» или «Send-URI«, поскольку принтер обнаружил ошибку доступа при попытке проверить доступность или доступ к данным Document (документа), указанным в атрибуте операции «document-uri». Принтер МОЖЕТ также возвращать определенный код ошибки доступа к Document (документу), используя […]

Код состояния «client-error-document-format-error» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос, потому что принтер обнаружил ошибку в данных документа при его интерпретации. Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity». Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть атрибуты Job Template (шаблона работы), которые […]

Код состояния «client-error-compression-error» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос, поскольку данные документа не могут быть распакованы при использовании алгоритма, заданного атрибутом операции «compression». Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity». Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть атрибуты Job Template […]

Код состояния «client-error-compression-not-supported» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос, поскольку данные документа, как указано в атрибуте операции «compression», сжимаются способом, который не поддерживается принтером. Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity». Принтер ДОЛЖЕН вернуть этот код состояния, даже если есть другие атрибуты […]

Код состояния «client-error-conflicting-attributes» в IPP 1.1 информирует о том, что Запрос отклонен, поскольку некоторые значения атрибутов конфликтуют со значениями других атрибутов, которые этот документ не разрешает заменять или игнорировать. Принтер ДОЛЖЕН также возвращать в группе Unsupported Attributes (Неподдерживаемые атрибуты) конфликтующие атрибуты, предоставленные Клиентом. Смотри раздел 4.1.7 и раздел 4.2.1.2 из […]

Код состояния «client-error-charset-not-supported» в IPP 1.1 информирует о том, что Для любой операции, если Принтер IPP не поддерживает кодировку, предоставленную Клиентом в атрибуте операции «attributes-charset», Принтер ДОЛЖЕН отклонить операцию и вернуть этот код состояния и любые атрибуты «text» или «name» используя кодировку utf-8 (раздел 4.1.4.1 из RFC 8011). Код состояния […]

Код состояния «client-error-uri-scheme-not-supported» в IPP 1.1 информирует о том, что Схема предоставленного Клиентом URI в операции «Print-URI» или операции «Send-URI» не поддерживается. Смотри раздел 4.1.6.1 и раздел 4.1.7 из RFC 8011. Код состояния описан в: (раздел B.1.4.13 из RFC 8011)   Код состояния «client-error-uri-scheme-not-supported» в IPP 1.1 относится к классу […]

Код состояния «client-error-attributes-or-values-not-supported» в IPP 1.1 информирует о том, что в запросе на создание задания (Job Creation), если принтер не поддерживает один или несколько атрибутов, синтаксисов атрибутов или значений атрибутов, предоставленных в запросе, и клиент предоставил атрибут операции «ipp-attribute-fidelity» со значением «true», принтер ДОЛЖЕН вернуть этот код состояния. (раздел B.1.4.12 из […]

Код состояния «client-error-document-format-not-supported» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос, поскольку данные документа имеют формат, указанный в атрибуте операции «document-format» (формат документа), который не поддерживается принтером. (раздел B.1.4.11 из RFC 8011)   Эта ошибка возвращается независимо от предоставленного клиентом атрибута «ipp-attribute-fidelity«. Принтер ДОЛЖЕН вернуть этот […]

Код состояния «client-error-request-value-too-long» в IPP 1.1 информирует о том, что Объект IPP отказывается обслуживать запрос, поскольку один или несколько предоставленных Клиентом атрибутов имеют значение переменной длины, которое превышает максимальную длину, указанную для этого атрибута. (раздел B.1.4.10 из RFC 8011)   Объект IPP может не иметь достаточных ресурсов (памяти, буферов и […]

Код состояния «client-error-request-entity-too-large» в IPP 1.1 информирует о том, что Объект IPP отказывается обрабатывать запрос, потому что объект запроса больше, чем объект IPP хочет или может обработать. (раздел B.1.4.9 из RFC 8011)   Принтер IPP возвращает этот код состояния, когда он ограничивает размер заданий на печать, и получает задание на […]

Код состояния «client-error-gone» в IPP 1.1 информирует о том, что Запрашиваемый объект больше не доступен, а адрес пересылки неизвестен. (раздел B.1.4.8 из RFC 8011)   Это условие следует считать постоянным. Клиенты с возможностями редактирования ссылок должны удалять ссылки на URI запроса после одобрения пользователя. Если объект IPP не знает или […]

Код состояния «client-error-not-found» в IPP 1.1 информирует о том, что Объект IPP не нашел ничего соответствующего URI запроса. Не указывается, является ли состояние временным или постоянным. (раздел B.1.4.7 из RFC 8011)   Например, клиент со старой ссылкой на задание (URI) пытается отменить задание; тем не менее, тем временем задание могло […]

Код состояния «client-error-timeout» в IPP 1.1 информирует о том, что Клиент не выдал запрос в течение времени, когда объект IPP был готов ждать. (раздел B.1.4.6 из RFC 8011)   Например, Клиент выполнил операцию «Create-Job«, а затем, через длительный период времени, выполнил операцию «Send-Document«; этот код состояния ошибки был возвращен в […]

Код состояния «client-error-not-possible» в IPP 1.1 информирует о том, что Этот код состояния используется, когда осуществляется запрос на то, что не может произойти. (раздел B.1.4.5 из RFC 8011)   Например, может возникнуть запрос на отмену задания (cancel a Job), которое уже было отменено или отменено системой. Клиент IPP НЕ ДОЛЖЕН […]

Код состояния «client-error-not-authorized» в IPP 1.1 информирует о том, что Запрашивающая сторона не авторизована для выполнения запроса. (раздел B.1.4.4 из RFC 8011)   Дополнительная информация аутентификации или учетные данные авторизации не помогут, и запрос НЕ СЛЕДУЕТ повторять. Этот код состояния используется, когда объект IPP хочет показать, что информация аутентификации понятна; […]