Кратко

  • FEAT позволила запросить документированные расширения FTP, не пробуя каждую потенциально действующую команду; OPTS выбирала режим для последующей команды.
  • Корректный положительный список был полным, но ответы 500 и 502 не доказывали отсутствия расширений: старые серверы могли поддерживать механизмы, появившиеся до FEAT.
  • Объявленная возможность, принятый параметр, личность, разрешение, финальный ответ, канал данных и наблюдаемое состояние файла оставались разными свидетельствами.

Когда проверка уже была воздействием

Базовый FTP из RFC 959 со временем получил новые команды и механизмы. Их внедряли не одновременно. Клиент мог знать спецификацию расширения, но не знать состояние конкретного сервера, к которому подключился.

Попытка выполнить команду давала практический ответ. RFC 2389 указала на цену такого метода: перебор создавал лишние обмены, а команда, посланная ради распознавания, могла вызвать нежелательный эффект. Интерфейс действия использовался как интерфейс описания.

FEAT добавила чтение перед действием. Команда не принимала аргументов; сервер отвечал структурированным перечнем поддерживаемых расширений. Клиент сопоставлял его со своими знаниями и решал локально, чем пользоваться. Значение метки и параметров по-прежнему определяла спецификация самого расширения.

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

Один пробел отделял содержание от конца

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

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

Неизвестная метка тоже не считалась ошибкой. Новый сервер мог поддерживать то, чего ещё не знал старый клиент. Клиент игнорировал непонятный элемент и продолжал работу с общим подмножеством. Будущее протокола не делало прошлое несовместимым.

Сами FEAT и OPTS в перечень не включались. Любой ответ, кроме 500 и 502, уже показывал понимание FEAT, а реализация OPTS была обязательна вместе с ней. Список не претендовал на описание всего состояния сеанса.

Положительный ответ был полным только в своей области

Сервер, реализовавший FEAT, обязан был перечислить все поддерживаемые и должным образом документированные расширения сверх RFC 959 и RFC 2389. Поэтому корректный успешный список имел сильное свойство: отсутствие расширения в нём означало отсутствие поддержки на этом сервере.

Однако ошибка 500 или 502 говорила только о незнании команды FEAT. Расширения существовали до появления общего перечня. Старый сервер мог выполнять одну из таких команд, не умея сообщать о ней новым способом. Ради совместимости клиент иногда должен был провести отдельную проверку старого расширения.

Даже сервер, который понимал FEAT, но не имел дополнительных функций, предпочтительно отвечал одной строкой 211, однако мог вернуть 500 или 502. С точки зрения клиента пустой перечень и отсутствие механизма перечня оказывались практически неразличимы.

Так возникла односторонняя завершённость доказательства. В корректном успешном перечне пропуск имел значение. Неудача получения перечня такого значения не имела. Спецификация не стала приписывать старым развёртываниям заявление, которого они никогда не делали.

OPTS меняла следующий шаг, а не подтверждала итог

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

Ответ 200 означал, что цель и параметры распознаны и допустимы. 501 указывал на постоянную ошибку при неизменном состоянии, 451 — на временное условие сервера. Ни один из них не означал, что целевая операция уже выполнена.

RFC 3659 показала это на MLST. В строке возможности сервер перечислял поддерживаемые факты о файлах и отмечал звёздочкой факты по умолчанию. OPTS MLST меняла набор для последующих ответов MLST и MLSD. Некоторые дополнительные факты могли требовать дорогих вычислений, поэтому их не рекомендовалось запрашивать без эксплуатационной причины.

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

Объявление TLS ещё не защищало канал

RFC 4217 использовала FEAT для FTP поверх TLS. Совместимый сервер объявлял AUTH TLS, PBSZ и PROT. Перечень показывал доступный путь согласования, но не создавал защищённый сеанс.

Клиенту ещё требовалось отправить AUTH TLS, получить 234, завершить TLS-обмен, установить параметры защиты, проверить личность сертификата по своей политике и пройти необходимую аутентификацию пользователя FTP. Строка возможности не выдавала полномочий и не гарантировала защиту будущего канала данных.

RFC 7151 повторила ту же границу с HOST. Метка сообщала о виртуальных хостах, но выбор хоста мог сменить среду аутентификации. Имя всё равно требовалось сопоставить с сертификатом. Узнать о двери, выбрать дверь и доказать право входа — три разных действия.

Реестр охранял имена, а не выдавал одобрение

RFC 5797 создала реестр команд и расширений FTP в IANA. Его задачей было предотвращать столкновения имён и возникающую двусмысленность. Реестр фиксировал команду, код FEAT, описание, тип, требования соответствия и ссылку. Исторические имена сохранялись, чтобы их не заняли заново.

Документ прямо предупреждал: регистрация не доказывает, что расширение «одобрено». Основанием могла быть постоянная общедоступная спецификация или реализация в широко доступных клиентах и серверах. Псевдокоды резервировали названия и не предназначались для реального ответа FEAT.

Реестр отвечает за однозначность названия. Сервер отвечает за своё локальное объявление. OPTS фиксирует принятый выбор. Системы личности и политики отвечают за разрешение. Работающая команда и канал данных отвечают за результат. Если таблица имён начинает изображать все эти полномочия, тонкая координация превращается в необоснованную власть.

Ограниченное раскрытие вместо разведки действием

RFC 2389 признавала, что список возможностей раскрывает сведения о сервере. Без FEAT настойчивый наблюдатель мог проверять команды по одной, хотя такая разведка могла быть заметнее в журналах. Авторы не сочли разницу достаточной для отказа от структурированного обнаружения.

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

Наследие RFC 2389 — в последовательности вопросов. Сначала: «какие дополнительные механизмы ты объявляешь?» Затем: «примешь ли ты этот режим?» И только потом: «разрешена ли операция и чем она закончилась?» Первый ответ делает решение лучше, но не присваивает себе доказательства последующих этапов.

Источники