Кратко

  • Ответ 340 разрешал передать статью; итоговые 240 или 441 появлялись лишь после полного тела.
  • Разрыв мог скрыть положительный ответ, уже отправленный сервером, не отменяя выполненного приема.
  • Тот же Message-ID связывал повтор с одной статьей, но не гарантировал немедленную видимость или exactly-once.

Неизвестность возникала после завершения передачи

Клиенту больше нечего посылать. Все строки дошли, включая точку-терминатор. Если обратный путь исчезает в этот момент, два разных исхода выглядят одинаково: сервер отказал либо принял, но его подтверждение потерялось.

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

У команды POST было два решения

RFC 977 задавал первоначальный ответ 340, приглашающий отправить статью, и 440, запрещающий публикацию. После полного материала сервер выдавал 240 для успеха или 441 для неудачи.

Первое согласие не означало приема — лишь открывало ввод. RFC 3977 сохранил схему, запретил конвейерную отправку POST и отделил ответы на команду от вердикта после завершающей последовательности.

240 должен был означать, что при отсутствии непредвиденных ошибок статья станет доступна локально или будет передана дальше, возможно после дополнительной обработки. Нежелательный материал следовало отклонить кодом 441, а не принять и молча удалить.

Прием и чтение оставались разными состояниями

Без положительного финального ответа клиент не должен считать передачу успешной. Но и после 240 нельзя полагать, что статья уже доступна читателям: это проверяется отдельно, например командой STAT.

RFC 5537 разделяет роли. Posting agent готовит proto-article, injecting agent проверяет и вводит его, модератор может обработать материал, relaying agents распространяют его, а serving agent показывает читателям. Совмещение ролей в одном продукте не превращает их свидетельства в одно событие.

Поэтому отсутствие статьи в чтении может означать очередь модерации или задержку конкретного сервера. Оно не восстанавливает утраченный результат предыдущей сессии.

Повтор должен был называть тот же объект

RFC 3977 прямо описывает прерывание до получения ответа: положительный ответ мог быть отправлен и потерян. В следующей сессии клиенту следовало проверить успех перед повтором либо обеспечить выделение той же Message-ID новой попытке.

Второй путь предпочтительнее, потому что статья еще может быть невидима, например во время модерации. Приложение рекомендует одинаковое содержимое поля Message-ID во всех POST и распознавание сервером этих попыток как одной статьи.

Идентификатор не доказывает успех первой транзакции, авторство или целостность. Он не позволяет восстановлению объявить второй объект. Новая Message-ID превращает тот же текст в отдельный материал с собственной модерацией, распространением и сроком хранения.

История подавляла дубли, а не все сбои

RFC 5536 определяет Message-ID как уникальный идентификатор и подчеркивает зависимость Netnews от быстрого сравнения. При flood-fill одна статья приходит от нескольких соседей, поэтому RFC 5537 требует от relay- и serving-агентов хранить историю увиденных ID.

Стабильный ID позволяет сопоставить повтор уже известной статье. Это не гарантия exactly-once: историю нельзя хранить бесконечно, локальные политики расходятся, а отказ возможен по обе стороны записи состояния. Зато оператор получает две попытки над одной идентичностью, а не две похожие статьи. Получение тела, ответ, инъекция, модерация, relay и видимость остаются отдельными проверяемыми этапами.

Реестр параметров NNTP IANA регистрирует возможность POST со ссылкой на RFC 3977. Он не доказывает право публикации на конкретном сервере или срок его истории.

NNTP не мог вернуть исчезнувший ответ. Он мог удержать восстановление в границах того же имени. Благодаря этому неопределенность одного действия не обязана была порождать вторую статью.

Sources