Спецсимволы в строке прокси: percent-encoding без двойного декодирования

Основная идея

В URI символы @ и : разделяют userinfo, host и port, а percent-encoding передаёт данные без этой структурной роли. Если приложение декодирует дважды или склеивает строку вручную, пароль меняется либо часть становится hostname.

В статье «Спецсимволы в строке прокси: percent-encoding без двойного декодирования» важно не приписывать протоколу свойства сервиса. Стандарт описывает формат сообщений и обязательное поведение сторон, а коммерческий продукт отдельно определяет географию, ротацию, срок и поддерживаемые команды. Чёткое разделение помогает понять, почему одна программа принимает строку подключения, а другая требует отдельные поля или вообще не поддерживает нужный режим.

Что подтверждает первичный источник

Проверяем parse/serialize на синтетических логинах и паролях с @, :, %, Unicode и не раскрываем реальные реквизиты.

Первичный источник «RFC 3986 — URI Syntax, WHATWG URL Standard, curl manual, MDN URL, MDN URLSearchParams» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Таблица содержит десять синтетических пар. Для каждой выполните programmatic serialize, parse и запрос к своему proxy-auth echo, который возвращает только hash username/password. Добавьте malformed percent escape и double-encoded %2540. Они должны дать явную validation error или отличимый hash, а не тихо авторизовать другого пользователя.

Проверка шаг за шагом

Используйте только canary credentials со знаками @ : % / пробелом и Unicode. Сформируйте URL через стандартный API, распарсьте, один раз извлеките поля и сравните с исходными байтами. Отдельно проверьте host:port:login:password формат, который не является URI.

Начните с матрицы возможностей: схема адреса, TCP или UDP, локальное или удалённое разрешение DNS, способ авторизации и поддержка IPv6. Заполняйте её по документации клиента и прокси, а не по названию настройки. Затем проверяйте по одной возможности на собственном endpoint, начиная с простого TCP-запроса и только потом добавляя DNS, TLS и прикладной сценарий.

При сбое сохраните границу, на которой он возник: разбор адреса, выбор метода авторизации, открытие туннеля, TLS или ответ origin. Коды разных уровней нельзя складывать в одну категорию. Ошибка SOCKS, отказ HTTP CONNECT и статус 403 конечного сайта требуют разных действий, хотя пользователь во всех трёх случаях видит неоткрывшуюся страницу.

• Создать canary-набор
• Сериализовать стандартным API
• Сравнить hashes полей
• Отклонить malformed и double-encoded cases

Какие данные сохранить

Сохраняйте case ID, безопасный набор символов, serialized string только с masked userinfo, parser version, decoded-field hashes, status и error category.

Полезная трассировка содержит протокол и версию, команду клиента, адрес назначения в обезличенном виде, код ответа посредника и код origin. Для DNS отдельно указывайте, кто разрешал имя. Пакетный дамп используют только на тестовом стенде и очищают от полезной нагрузки; для большинства разборов достаточно подробного лога клиента без реквизитов.

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

Как читать результат

Логи должны маскировать userinfo до любых ошибок parser. Не передавайте строку через shell interpolation: даже корректный URL может быть интерпретирован оболочкой до запуска клиента.

WHATWG URL и generic RFC parser могут различаться. Некоторые proxy tools используют собственный не-URI формат и требуют отдельной спецификации.

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

Разбор рабочего решения

В практическом разборе «Спецсимволы в строке прокси: percent-encoding без двойного декодирования» заведите матрицу из строк «возможность» и столбцов «стандарт», «прокси-сервис», «клиент» и «проверено». Например, удалённый DNS может быть предусмотрен форматом SOCKS5, поддерживаться сервисом, но не включаться конкретной библиотекой. Только пересечение четырёх столбцов даёт рабочую функцию. Ссылка на RFC без проверки клиента и зелёный ответ клиента без понимания протокола одинаково недостаточны.

Снимайте минимальную трассу, которая отвечает на вопрос. Для HTTP CONNECT обычно нужны адрес посредника, строка назначения, код посредника, состояние TLS и код origin. Для SOCKS добавьте команду, тип адреса и код ответа. Для DNS укажите, где разрешилось имя. Эти данные позволяют отличить синтаксическую ошибку от запрета политики и сетевого таймаута, не сохраняя полезную нагрузку, cookies или пароль.

После успешного опыта проверьте границы совместимости: вторую версию клиента, один альтернативный формат адреса и контролируемый отказ. Результаты занесите в таблицу поддержки продукта. Не превращайте единичное наблюдение в обещание для всех программ. Если функция зависит от версии, платформы или режима DNS, это должно быть написано рядом с примером подключения, а не спрятано в ответе поддержки.

Типичные ошибки

Распространённые ошибки — путать SOCKS5 с шифрованием, ожидать UDP от любого клиента, записывать IPv6 без квадратных скобок рядом с портом и считать HTTP/2 гарантией ускорения. Проверяйте конкретную реализацию. Даже предусмотренная стандартом команда может быть сознательно отключена сервисом или библиотекой.

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

Критерии внедрения и сопровождение

Перед внедрением сформулируйте критерий решения: какое наблюдение разрешает продолжить работу, какое требует ручной проверки, а какое немедленно останавливает процесс. Укажите допустимый процент ошибок, максимальное время ожидания и владельца исключения. Без этих границ команда начинает объяснять одинаковый результат по-разному, а временный сбой незаметно превращается в постоянную настройку.

Через неделю после запуска проверьте, совпадают ли фактическая нагрузка, расходы и качество с тестом. Затем назначьте регулярный малый контроль и повторную проверку после обновления клиента, прокси-сервиса или сетевой схемы. Устаревшую инструкцию архивируйте вместе с датой и причиной замены, чтобы сотрудники не использовали две конфликтующие конфигурации.

Рабочий регламент

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

• Названа версия протокола
• Проверены возможности клиента
• DNS-маршрут указан отдельно
• Различены прокси и origin-коды
• Тест начат с минимального запроса
• Неподдерживаемая функция не обещана пользователю