Разбор URL

Интеграции OAuth и OpenID Connect ломаются из‑за мелочей: лишний слэш в конце path, неверный порт или http вместо https. Провайдеры сравнивают зарегистрированный redirect_uri буквально с тем, что приложение шлёт в authorization request. Перед вставкой в Google, Microsoft или Okta разберите URI в DN01 и убедитесь, что схема, hostname, path и query совпадают с allowlist посимвольно. Если callback собирается динамически, вставьте значение из неудачного входа и сравните origin и нормализованный URL с зарегистрированным. Расхождение в регистре hostname обычно безвредно — инструмент приводит host к нижнему регистру, а вот лишний query-параметр или другой path сломает поток. Проверка бесплатна и избавляет от круговых ошибок на стороне провайдера.

Маркетинг помечает ссылки UTM-параметрами для атрибуции в аналитике. Со временем появляются опечатки (utm_source против utm_Source), дубли ключей и кодирование, незаметное в таблице. Вставьте каждый landing URL в сплиттер и читайте таблицу query-параметров вместо ручного подсчёта амперсандов. Можно проверить utm_medium, utm_campaign и utm_content до рассылки и поймать двойной ? при склейке URL. Парсинг локальный — можно смотреть неопубликованные ссылки с закрытыми slug.

Операторы CDN и reverse-proxy пишут cache key и origin rules из частей URL. Правило на /images/* не должно случайно включать query, ломающий кэш, а маршрутизация по hostname должна отличать www от apex. Разбор проблемного request URL показывает, совпадают ли сегменты path с порядком edge-правил и влияет ли порт в host на dev-среде. При миграции с prefix на segment-роутинг сравнение списков сегментов проясняет, какие каталоги нужны в карте редиректов.

Отладка webhook часто начинается со строки лога с полным callback URL. Платёжные системы, GitHub и CI показывают точный адрес, который пытались вызвать. Вставьте URL, чтобы отделить path для роутера от query, который верификация подписи может учитывать или игнорировать. Если слушатель на нестандартном порту, поле port подтверждает, указали ли :443 явно. Это быстрее, чем искать двоеточие в длинной HTTPS-строке.

SPA часто переносят состояние во фрагмент (#/dashboard?tab=billing), который серверные логи не видят. Когда пользователь жалуется на «не ту страницу после входа», разберите URL из адресной строки и смотрите фрагмент отдельно от path и query. Поддержка объяснит, проблема в серверной маршрутизации или в клиентском роутере. DN01 фиксирует: фрагмент разбирается для анализа, но в классической строке access log его не будет.

При security review приходят подозрительные ссылки с запрещёнными схемами. DN01 принимает абсолютные http/https и отклоняет javascript:, data: и file: — безопасная практика разбора. Аналитик документирует схему и host для тикета без выполнения кода и без fetch. Для https извлечение hostname помогает перейти к WHOIS или DNS в других инструментах, оставаясь на структурном шаге.

API-шлюзы и mesh добавляют префиксы path при публикации внутренних сервисов. Снаружи https://public.example.com/payments/v1/charges, внутри — /v1/charges. Разбор внешнего и внутреннего представления по сегментам показывает дрейф префикса до выката route tables в production.

Ошибка «absolute URL with scheme and host is required» означает: добавьте https:// (или http://) перед хостом и уберите лишние пробелы. Запись example.com/path без схемы не является абсолютным URL для этого инструмента. Копируйте значение из адресной строки браузера.

Схемы javascript:, data: и file: блокируются намеренно — это не веб-навигация для redirect или CDN. Перепишите ввод как https, если изучаете страницу из другого контекста, или уберите исполняемую нагрузку перед разбором.

Если query-параметры пусты, хотя после ? должны быть значения, проверьте кодирование. Битая percent-последовательность ломает парсинг. Вставляйте URL так, как он был в логе, письме или JSON, а не частично декодированный вариант.

Когда host и hostname отличаются только портом, правило маршрутизации может требовать явного порта. Для https по умолчанию :443 не показывается; для :3000 поле port будет непустым. Нормализованный URL не убирает кастомный порт — он сохраняет ввод.

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

Схема задаёт ожидания транспорта. В production OAuth-провайдеры требуют https для redirect_uri, локально иногда разрешают http на localhost. Отдельное поле scheme помогает думать о mixed content и HSTS без перечитывания RFC. Для не-http схем, которые иные утилиты всё же парсят, DN01 может предупредить об отсутствии сетевого доступа — здесь первичны http и https.

Разделение host и hostname отражает RFC 3986 и то, как API серверов отдают peer name. SNI в TLS использует hostname; сокеты слушают порт. Health check CDN бьёт в hostname:443, а docker-сервис публикует host:8080 в bridge-сети. Оба поля снижают путаницу, когда «хост» в разговоре означает только DNS-имя.

Path и сегменты поддерживают и строковые, и REST-представления. Прокси документируют prefix-правила; код приложения режет сегменты для авторизации. Percent-encoding в path — как на проводе, сравнение с access log остаётся честным. Список сегментов без пустых частей от краевых слэшей соответствует интуитивным «папкам».

Два представления query нужны, потому что аналитика и подписи смотрят на разное. Маркетингу важны декодированные utm_campaign; HMAC webhook может требовать сырой substring query как в запросе. Дубликаты ключей видны сразу; пустое значение — отдельный случай от отсутствующего ключа.

Фрагмент — самая недооценённая часть URL. При класической загрузке страницы браузер запрашивает только часть до #; фрагмент обрабатывается локально после ответа. Поэтому смена фрагмента не даёт новой строки в server access log. Исторические implicit OAuth-потоки возвращали токены во фрагменте — security review обязан их смотреть, даже если nginx их не видит. DN01 показывает фрагмент для обучения и SPA, а не как серверный маршрут.

Origin и нормализованный URL помогают сравнивать эквивалентность. Origin — граница безопасности для CORS и разделения Web Storage. Нормализация приводит scheme и host к нижнему регистру по правилам инструмента. Используйте для allowlist, но уточните у IdP, чувствителен ли path к регистру, прежде чем полагаться только на normalization.

Ручное разрезание в редакторе сгодится для одного URL, но плохо масштабируется на длинные query. Один лишний & или = внутри base64 ломает наивный split. DN01 использует полноценный парсер в духе Go net/url — меньше сюрпризов на краях.

Network в DevTools показывает URL только после запроса. Для redirect_uri или закрытых кампаний запрос может быть нежелателен. Локальный разбор даёт структуру без сетевых побочных эффектов.

One-liner в Python или Node гибки, но неудобны маркетингу и поддержке. DN01 даёт единую таблицу на вашем языке и shareable result pages без установки runtime.

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

Онлайн-парсеры по-разному показывают части и иногда ходят на удалённый сайт. DN01 заточен под абсолютные http/https без fetch и с отклонением опасных схем.

curl -I и wget проверяют доступность, смешивая DNS, TLS и HTTP status со структурой URL. Сначала DN01, потом проверка доступности.

RFC 3986 полезен для глубины, но медленен в инциденте. DN01 операционализирует поля, которые нужны дежурным, в табличном виде.