Summary

  • Код INPROGRESS передаётся внутри нетегированного OK: он может содержать счётчик, оставлять общий объём неизвестным или быть лишь сигналом для сохранения соединения.
  • Команду завершает ответ с её тегом — OK, NO либо BAD. Собственно данные результата и последствия в других системах подтверждаются отдельно.

Число 999 из 1 000 кажется почти завершённой работой. Для человека это повод перестать беспокоиться. Для автоматики — соблазн заранее разблокировать следующий этап. Однако сервер сообщил только значение внутри своей модели прогресса.

По RFC 9585 после такой отметки цель может измениться, а прогресс — отступить назад. Сервер мог закончить один фрагмент и обнаружить новый. Команда всё ещё способна завершиться ошибкой. И обработанные единицы вовсе не обязаны совпадать с числом полезных результатов.

Расширение появилось из практической потребности. Поиск или копирование в большом почтовом ящике может занимать долгое время, а молчание сервера не отличает вычисление от зависшего соединения. Свободный текст был возможен и раньше, но клиент не мог надёжно интерпретировать его. Опубликованный в мае 2024 года RFC 9585 ввёл единые capability и response code INPROGRESS.

Сначала сервер объявляет возможность. Если расширение поддерживается, INPROGRESS должен присутствовать в ответе CAPABILITY. Это доказывает поддержку механизма, но не обещает уведомление для каждой команды. Быстрая операция может завершиться до первого рекомендуемого интервала и не послать ни одного промежуточного сообщения.

Когда сервер решает уведомлять клиента, рекомендован интервал в 10–15 секунд. Целью может быть лишь предотвращение тайм-аута. В самой простой форме подробностей нет, поэтому тег команды, прогресс и цель трактуются как NIL. Это признак активности соединения, а не измерение выполненной работы.

Полная форма содержит CMD-TAG, PROGRESS и GOAL. Тег по возможности связывает уведомление с исходной командой. Прогресс показывает количество обработанных элементов, а положительная цель — ожидаемое общее число при завершении. Когда предметных единиц нет, допустима процентная шкала: цель 100, прогресс от 0 до 99.

Неизвестные значения предусмотрены протоколом. Если прогресс недоступен, прогресс и цель должны быть NIL. Если неизвестен лишь общий объём, GOAL остаётся NIL. Если тег недоступен либо содержит ], значение тега тоже становится NIL. При одной выполняемой команде анонимный импульс ещё полезен; при нескольких его нельзя уверенно отнести к конкретной операции.

Стабильность чисел также не гарантируется. Прогрессу следует расти, цели — не меняться, но клиент обязан выдерживать обратное. Рекомендованное толкование таково: прежняя цель была достигнута, после чего сервер обнаружил дополнительную долгую работу. Это правило обработки ситуации, а не доказательство причин и не расчёт оставшегося времени.

Главную границу задаёт синтаксис IMAP4rev2. Нетегированные ответы начинаются со * и несут данные либо статус, который не завершает команду. Итоговый ответ повторяет клиентский тег и имеет форму OK, NO или BAD. Поэтому INPROGRESS разрешён только внутри нетегированного OK и запрещён в тегированном ответе.

Само слово OK способно ввести в заблуждение. * OK [INPROGRESS ...] не равен A001 OK, завершающему команду A001. Звёздочка означает, что история продолжается; совпавший тег её закрывает. Если интерфейс или журнал скрывает это различие, он приписывает сигналу полномочия, которых протокол не давал.

Успешное завершение ещё не раскрывает содержание результата. В примере SEARCH промежуточные ответы называют число обработанных элементов. Затем нетегированный ответ SEARCH возвращает идентификаторы совпавших сообщений. Только после этого приходит тегированный OK. Цель не является числом совпадений, прогресс — набором результатов, а финальный OK — самим набором.

RFC 9585 прямо запрещает считать эти значения авторитетными вне оценки прогресса. В частности, GOAL нельзя использовать вместо штатного вывода SEARCH для подсчёта сообщений в папке. У COPY та же граница: обработанное количество не доказывает, сколько объектов устойчиво записано, проиндексировано, реплицировано или принято внешним архивом.

Отсутствие уведомления тоже ничего не доказывает. До первого сообщения клиент принимает прогресс за ноль, а цель — за неизвестную. Это описание знаний клиента, а не состояния сервера. Короткая команда может успешно закончиться без прогресса; неисправный сервер может, наоборот, слать импульсы без полезного результата.

Числа следует проверять как недоверенный ввод. В разделе безопасности перечислены значения, способные вызвать арифметические ошибки. Нулевые или отрицательные цели, чрезмерные величины и прогресс выше цели нужно игнорировать. Изменения цели и откаты сохраняются в исходной последовательности, а не сглаживаются ради красивого графика.

Практическая реализация строится вокруг состояний. Для команды фиксируются соединение, аутентифицированная сессия, объявленная capability, тег, время отправки и параллельные операции. Все уведомления сохраняются отдельно от содержательного вывода. Состояние «выполняется» меняется лишь после соответствующего тегированного ответа. Если значимый эффект находится вне IMAP, затем проверяется целевая система.

Тегированный OK остаётся квитанцией самого IMAP-сервера. Он не доказывает автоматически, что архив построил индекс, реплика сошлась, правило хранения выполнено или клиент получил уведомление. Каждая новая система добавляет новое утверждение и требует собственного подтверждения.

RFC 9585 уменьшает слепую зону долгих операций. Он не отменяет необходимость дождаться нужной квитанции.

Sources