Кратко

  • FTP считал USER, PASS и ACCT разными данными управления доступом. Успех парольного шага не доказывал завершённый вход или разрешение любой последующей операции.
  • 332 был положительным промежуточным ответом. После файловой команды он также означал, что сервер сохранил её в ожидании счёта; 532 означал, что команда отброшена и после ACCT её нужно повторить.
  • Стандарт не задавал универсального смысла account. Локальная система могла связать строку с проектом, ресурсом, учётом или полномочиями; документы не доказывают секретность, оплату, современное распространение или успех передачи.

Между правильным секретом и готовой сессией

Клиент посылает USER, сервер просит пароль, затем получает PASS. Если иных сведений не нужно, RFC 959 допускает 230 User logged in. Но серверу может требоваться account для входа, и тогда ответ — 332 Need account for login.

Первая цифра 3 не означает отказ. Предыдущая команда принята, однако действие приостановлено до получения дополнительной информации. Клиент должен послать ACCT, а не снова проверять уже принятый пароль.

Так протокол сохранял различие, неудобное для двухполейных интерфейсов: подтверждение секрета пользователя и выбор локального контекста ресурсов были разными решениями.

Третья команда появилась из требований TENEX

RFC 385 добавил ACCT в августе 1972 года. Документ прямо ссылался на системы вроде TENEX, которым помимо пользователя и пароля требовалось отдельное указание счёта.

Команда отличалась от PASS: она не обязана была быть жёстко связана с USER, могла поступить в любой момент, а один пользователь мог передавать разные файлы под разными accounts. Иногда она завершала вход, иногда требовалась лишь для конкретного доступа, например записи.

Слово account не устанавливает финансовый смысл. FTP стандартизовал Telnet-строку, но оставил её интерпретацию удалённой системе. Проект, распределение вычислительных ресурсов, область полномочий или центр затрат — возможные местные модели, а не утверждения RFC.

Состояние сохранилось, хотя номера сменились

В 1973 году RFC 542 включил ACCT в управление доступом. Старый словарь использовал 331 Enter account для дополнения входа и 433, когда передача без действительного счёта не могла продолжаться и команду следовало повторить.

RFC 640 перестроил ответы, чтобы автомат выбирал следующее состояние по цифрам, а не разбирал свободный текст сервера. Класс 3yz стал положительным промежуточным, 5yz — отрицательным завершением точного запроса; x3z объединил authentication и accounting.

После этого 331 стал запросом пароля, 332 — счёта для входа, 532 — счёта для хранения файлов. Старую трассу нельзя читать по новой таблице: одинаковая цифра в разные годы задавала разные вопросы.

332 оставлял намерение серверу, 532 возвращал его клиенту

RFC 765, а затем RFC 959 описали ситуацию после входа. Клиент отправляет STOR, но локальная политика требует для этой записи account.

Если сервер хранит STOR и ждёт только ACCT, он отвечает 332. Если он отбрасывает команду, ответ — 532. Во втором случае успешный ACCT создаёт нужный контекст, но не воскрешает потерянную операцию: клиент обязан повторить STOR.

Коды подтверждали, где находится намерение. Они не были двумя формулировками одного сбоя. Обобщённое исключение «account required» не говорит программе, отправить ли только сведения или ещё и саму операцию.

532 не сообщал о заполненном диске

Фраза “for storing files” легко вводит в заблуждение. Для ёмкости RFC 959 использует другие ответы: 452 означает недостаток пространства в системе, 552 — превышение выделенного объёма текущего каталога или набора данных.

Недостающий контекст, нехватка физического ресурса и исчерпанная квота требуют разных действий. Сведение их к «storage failure» заставляет расширять диск вместо выбора счёта или повторять запрос, который сервер уже уничтожил.

Соединение продолжалось, а контекст доступа мог исчезнуть

Новый USER на той же управляющей связи стирает прежние user, password и account и начинает вход заново, говорит RFC 959. Параметры передачи сохраняются, а уже идущая передача завершается под прежними правилами доступа.

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

Поэтому для аудита недостаточно идентификатора соединения. Перед каждой операцией нужна последняя последовательность USER, ACCT, REIN и переподключений. Некогда принятый счёт не доказывает текущий контекст.

Поддерживать ACCT не значило требовать его всегда

RFC 1123 включил ACCT в минимальный набор для клиента и сервера с оговоркой о возможностях базовой файловой или операционной системы. Это позволяло взаимодействовать с узлами, где третий шаг действительно был нужен.

Документ не обязывал каждый сайт требовать счёт. Понятая, но избыточная локально команда могла получить положительный 202. Поддержка языка и единая политика использования — не одно и то же.

Реестр команд и расширений FTP IANA по-прежнему показывает ACCT как базовую команду управления доступом со ссылкой на RFC 959. Запись доказывает синтаксис и источник, но не распространённость, значение строки или результат передачи.

Протокол не притворялся, что решение уже принято

FTP не унифицировал accounts разных компьютеров. Он дал серверу право запросить локальный контекст, а клиенту — узнать, прошёл ли пароль, завершён ли вход и сохранилась ли предыдущая команда.

Долговечен не конкретный старый параметр, а отказ смешивать доказательство субъекта, выбор ресурсной области и принятие действия. Если современная система сжимает всё в один флаг authentication, исчезнувшие состояния возвращаются общими секретами, частными скриптами и отказами без объяснимой причины.

Источники и пределы

Набор включает RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 и IANA. Они устанавливают семантику и историю, но не поведение конкретного сервера, нынешнее использование, конфиденциальность, оплату или завершение файла.