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

Версия документа от 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 2. […]

Аннотация В этом документе регистрируются схемы проверки подлинности по протоколу гипертекстовой передачи (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 Error. […]

Код состояния "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 хочет показать, что информация аутентификации понятна; однако […]

Код состояния "client-error-not-authenticated" в IPP 1.1 информирует о том, что Запрос требует аутентификации пользователя. (раздел B.1.4.3 из RFC 8011) Клиент IPP может повторить запрос с подходящей информацией для аутентификации. Если в запрос уже включена информация об аутентификации, то этот код состояния указывает, что в авторизации было отказано для этих учетных […]

Код состояния "client-error-forbidden" в IPP 1.1 информирует о том, что Объект IPP понял запрос, но отказывается его выполнить. Дополнительная информация аутентификации или учетные данные авторизации не помогут, и запрос НЕ СЛЕДУЕТ повторять. Этот код состояния обычно используется, когда объект IPP не хочет точно указывать, почему запрос был отклонен или когда […]

Код состояния "client-error-bad-request" в IPP 1.1 информирует о том, что Запрос не может быть понят объектом IPP из-за неправильного синтаксиса (например, значения атрибута фиксированной длины, длина которого не соответствует предписанной длине для этого атрибута - см. Руководства разработчика [RFC3196] [PWG5100.19]). Приложение IPP НЕ ДОЛЖНО повторять запрос без изменений. (раздел B.1.4.1 […]

"Ошибки клиента" (Client Error) значения кодов состояния в IPP 1.1 - этот класс "значений кода состояния" (status-code values) предназначен для случаев, когда Клиент, похоже, допустил ошибку. Объекту IPP СЛЕДУЕТ возвращать сообщение, содержащее объяснение ситуации ошибки и является ли это временным или постоянным условием.(раздел B.1.4 из RFC 8011) К классу ответов операций […]

Код состояния "successful-ok-conflicting-attributes" в IPP 1.1 информирует о том, что Запрос выполнен успешно, но некоторые предоставленные значения атрибута конфликтуют со значениями других предоставленных атрибутов.(раздел B.1.2.3 из RFC 8011) Либо (1) эти конфликтующие значения были заменены (поддерживаемыми) значениями, либо (2) атрибуты были удалены, чтобы обработать задание, не отклоняя его. Атрибуты или […]

Код состояния "successful-ok-ignored-or-substituted-attributes" в IPP 1.1 информирует о том, что Запрос выполнен успешно, но некоторые предоставленные атрибуты (1) были проигнорированы или (2) неподдерживаемые значения были заменены поддерживаемыми значениями или были проигнорированы, чтобы выполнить операцию, не отклоняя ее. (раздел B.1.2.2 из RFC 8011) Неподдерживаемые атрибуты, синтаксисы атрибутов или значения ДОЛЖНЫ быть […]

Код состояния "successful-ok" в IPP 1.1 информирует о том, что Запрос выполнен успешно, и никакие атрибуты запроса не были заменены или проигнорированы. В случае ответа на запрос на "создание задания" (Job Creation), код состояния "successful-ok" указывает, что запрос был успешно получен и проверен, и что объект задания (Job) был создан; […]