Кратко

  • draft-ietf-httpbis-connect-tcp-14 задаёт TCP-прокси URI-шаблоном с target_host и target_port; после подстановки получается ресурс для соединения connect-tcp.
  • Шаблон выбирает origin, путь, пространство защиты и точку применения политики. Поэтому его происхождение входит в контур авторизации.
  • Last Call IETF завершается 1 октября 2026 года. Документ остаётся Internet-Draft, а не утверждённым RFC или свидетельством внедрения.

Строка конфигурации выбирает контролёра

Классический CONNECT передаёт прокси имя узла и порт. Версия 14 сначала предоставляет клиенту URI Template. Клиент подставляет целевые значения и обращается к полученному ресурсу на origin прокси.

Эта операция определяет, куда попадут учётные данные, какой путь выберет HTTP-шлюз и к какому origin будут привязаны HSTS, Alt-Svc, cookie и другое состояние. Шаблон не просто форматирует адрес: он указывает ворота.

Проект наследует правила RFC 9298. Шаблон должен быть абсолютным, иметь непустые scheme, authority и path, размещать переменные только в path или query, содержать оба целевых параметра и не использовать ряд операторов раскрытия. Обнаружив нарушение, клиент обязан отказаться от конфигурации до отправки запроса.

Проверка подтверждает допустимую структуру. Она не подтверждает, кто распространил шаблон, имел ли он право менять выход и принадлежит ли origin ожидаемой административной службе. Формально правильная подстановка не исправляет подменённый источник.

HTTP-ответ фиксирует только свою стадию

В HTTP/1.1 клиент отправляет GET на раскрытый URI и просит Upgrade: connect-tcp. Если запрос корректен и разрешён, прокси должен попытаться установить TCP до окончательного ответа. Успех даёт 101 Switching Protocols; без установленного TCP переключение запрещено.

В HTTP/2 и HTTP/3 прокси объявляет extended CONNECT. Клиент указывает :protocol = connect-tcp, authority прокси и путь из шаблона. Успешный CONNECT открывает поток для Capsule Protocol.

Expect: 100-continue выделяет более раннее событие. Код 100 означает, что запрос получен и не отклонён немедленно; рукопожатие с назначением ещё может продолжаться. Последующий 101 или успешный extended CONNECT сообщает, что прокси считает TCP установленным. Он не удостоверяет прикладную службу, её TLS-сертификат, доставку байтов или завершение операции.

Поэтому единый статус «успех» непригоден. Отказ политики до попытки, неудачный TCP и прикладная ошибка внутри готового туннеля требуют разных записей.

Учётные данные действуют в пространстве прокси

Явный HTTP-origin позволяет использовать 401, WWW-Authenticate и Authorization. Классические поля 407 не применяются, поскольку не проходят через обычные HTTP-gateway. Ресурсы одного шаблона обычно разделяют protection space; возможен и клиентский TLS-сертификат.

Это позволяет использовать маршрутизацию по пути, DDoS-защиту, очистку запросов и пользовательскую авторизацию. Высокоэнтропийный путь или concealed authentication могут скрыть службу от неавторизованного сканирования.

Но действительный credential отвечает на узкий вопрос: прошёл ли субъект схему аутентификации этого protection space. Разрешение host и port остаётся отдельной политикой. DNS выбирает адрес. TLS назначения проверяет другую личность. Приложение решает, допустимо ли действие.

RFC 9110 предупреждает: произвольные порты CONNECT могут превратить прокси в ретранслятор нежелательных протоколов. URI-шаблон не устраняет риск, а даёт политике более явное место.

DATA хранит порядок, FINAL_DATA — полузакрытие

TCP-данные идут в капсулах DATA. FINAL_DATA может содержать последние байты и одновременно означает FIN в этом направлении. После неё запрещены DATA и повторный FINAL_DATA. Полученный TCP FIN должен стать FINAL_DATA, а корректный FINAL_DATA — TCP FIN.

Границы капсул не обязаны совпадать с TCP-сегментами, TLS-record, HTTP-frame или прикладными сообщениями. Посредник может объединять и делить последовательные капсулы, сохраняя порядок байтов и тип последней.

Общий контракт защищает последовательность и направленное закрытие, но не смысл. Клиент мог записать данные в HTTP-поток, пока прокси хранит их как optimistic content. Прокси мог записать в TCP socket, хотя приложение ещё ничего не обработало. FINAL_DATA может передать FIN, а обратное направление закончится reset.

В HTTP/2 и HTTP/3 оптимистичные данные должны ждать, пока выбранное TCP-соединение станет доступным для записи, и удаляться при его отказе. При гонке адресов payload нельзя отправлять проигравшим соединениям. Отдельно фиксируются источник шаблона, сертификат прокси, аутентификация, политика, DNS, попытка TCP, HTTP-статус, DATA/FINAL_DATA, TLS назначения, счётчики, закрытие и наблюдаемый результат.

Last Call не равен рабочему коду

Сообщение IESG принимает комментарии до 1 октября. Datatracker отмечает активную версию 14, переданную IESG с предполагаемым статусом Proposed Standard.

Текст ещё может измениться, быть заменённым или истечь. Даже будущий RFC докажет протокольный договор, но не наличие реализации, совместимость gateway, корректность half-close или безопасную эксплуатационную политику.

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

Прокси может разрешить туннель. Он не может поручиться за всю реальность за ним.

Источники