Кратко

  • Изначально RFC 3196 оставляла реализации выбор: принимать ли документ целиком до окончательного ответа Print-Job. Техническая поправка 2924 закрыла эту свободу: сначала должны быть приняты все данные.
  • Правило относится к окончательному ответу IPP — и успешному, и ошибочному. 100 Continue по HTTP, ранняя транспортная ошибка, создание задания и физический вывод страницы — разные события.

Ответ раньше документа

Internet Printing Protocol (IPP) задумывался как способ превратить печать в сетевую службу. Клиент отправлял операцию по HTTP; для Print-Job сам документ также передавался в теле запроса. Принтер возвращал статус IPP, а при создании задания — идентификаторы для последующего запроса состояния. В этом обычном обмене скрывался практический вопрос: когда сервер вправе сообщить результат, если тело запроса ещё в пути?

Опубликованное в ноябре 2001 года руководство RFC 3196 по реализации IPP/1.1 изначально оставляло на усмотрение реализации, принимать ли весь документ до окончательного ответа об успехе или ошибке. Erratum 2924 в 2011 году изменил формулировку: принтер ОБЯЗАН принять все данные документа до отправки такого ответа. Это не новая функция печати. Поправка определила момент, после которого окончательный ответ может относиться к запросу, содержащему ещё передаваемый документ.

Для потоковой передачи это особенно существенно. Если приложение сообщает результат до завершения отправки, клиенту трудно понять, принята ли оставшаяся часть, создано ли задание и безопасен ли повтор. Для окончательного ответа IPP поправка закрепила границу на стороне принтера: сначала полный приём, затем ответ.

Три подтверждения с разным смыслом

Сфера правила ограничена. 100 Continue — промежуточный ответ HTTP: он разрешает клиенту продолжить отправку тела. Это не означает успех операции IPP. HTTP также допускает ранний окончательный ответ об ошибке, если метод не будет выполнен; обработка тела и соединения относится к транспортному уровню. Erratum не считает любое раннее сообщение нарушением.

Успешный ответ Print-Job также не доказывает, что бумага вышла из принтера. В ответе могут быть job-id и job-uri, чтобы клиент позднее запросил состояние задания. RFC 8010 и RFC 8011, опубликованные в 2017 году, обновили и заменили RFC 2910 и RFC 2911, сохранив разграничение транспорта HTTP, операции IPP и жизненного цикла задания. Приём документа, создание задания, обработка, печать и передача листа пользователю — отдельные этапы.

Документы подтверждают правило, но не его распространение. RFC 3196 имеет статус Informational и не является новой спецификацией протокола Standards Track. RFC Editor помечает Erratum 2924 как Technical; Майкл Свитт сообщил о нём в августе 2011 года, Питер Сент-Андре проверил в ноябре. Источники не показывают, какие продукты применили поправку и был ли конкретный сбой вызван прежней формулировкой. Приписывать ей историю отраслевого инцидента было бы необоснованно.

Практический вывод — всегда уточнять, какой уровень что именно подтвердил. Начало передачи не доказывает полный приём документа; идентификатор задания не доказывает печать. Поправка устранила одну определённую неоднозначность, не гарантируя последующие стадии.

Источники

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