Однажды я потерял день из-за URL-адреса, который выглядел нормально. Ошибка звонка OAuth продолжала, uri перенаправления "соответствовал" тому, что зарегистрирован у провайдера, и я не мог понять, почему сломалась рукопожатие. Ответ, когда я, наконец, вставил вещь в синтаксический анализатор, был скользящей косой по пути в одном месте, а в другом ни одной, плюс state Параметр, который был двойной кодировался, поэтому %20 стал %2520, йо- Для человеческого глаза два URL-адреса были идентичны. Для сервера OAuth они были разными струными, и было правильно отклонить несоответствие.
В этом проблема с URL-адресами: они плотные, их легко неправильно прочитать, а детали, которые ломают вещи - закодированная косая черта, случайный порт, повторяющийся ключ запроса, фрагмент, в котором вы ожидали пути - это именно те, которые прячутся в стене символов. Я строю [Toolz.dev](/, и я провожу достаточно времени, глядя на строки запроса во время отладки, что я построил URL-адрес сделать пристальное внимание для меня. Вставьте ссылку, получите каждый компонент, помеченный помеченным, и каждый параметр запроса декодируется в таблице. В этом руководстве объясняется, что это за компоненты, почему эти различия имеют значение и как их использовать.
TL;DR: URL-адрес состоит из схемы (
https), дополнительные учетные данные (user:pass@), хост (example.com) с дополнительным портом, путь (/blog/post), строка запроса (?id=42), и фрагмент (#section). выше URL-адрес Разделяет любую ссылку на те части, используя собственный движок URL-адреса браузера WhatWG, декодирует запрос в упорядоченную таблицу значений ключа (повторные ключи, сохраненные отдельно), показывает эффективный порт для схемы и предполагаетhttps://Если вы вставите голый домен. Он работает полностью в вашем браузере, поэтому ссылки с токенами остаются приватными.
Какие части URL?
Каждый URL следует одной и той же грамматике, определяемой стандартом WHATWG URL - спецификации браузеры действительно реализуют, Как только вы можете назвать части, большинство ошибок URL становятся очевидными Вот полная анатомия, используя намеренно занятой пример:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
Разбивая это:
| составляющий | Пример значения | Что это такое |
|---|---|---|
| схему | https |
протокол. Определяет порт по умолчанию и как делается запрос. |
| Имя пользователя | john |
Дополнительный сертификат, до @, йо- |
| пароль | s3cret |
Дополнительный сертификат после : в пользовательской информации. |
| имя хоста | shop.example.co.uk |
домен или IP-адрес без порта. |
| левый | 8443 |
необязательный. Возвращается к схеме по умолчанию при опущенном состоянии. |
| хозяин | shop.example.co.uk:8443 |
hostname plus port, когда присутствует порт. |
| происхождение | https://shop.example.co.uk:8443 |
Scheme plus host - браузеры устройств используют его для обеспечения безопасности. |
| тропа | /catalog/shoes |
Местоположение ресурса на хосте. |
| вопрос | ?color=red&size=42 |
Параметры ключ-значение после ?, йо- |
| фрагмент | #reviews |
клиентская якорь после #, никогда не отправляется на сервер. |
Парсер выкладывает каждую из них как свою собственную строку с помощью кнопки «Копировать», поэтому вам больше никогда не придется извлекать имя хоста из URL-адреса монстра. Он также помечает пару вещей, скрываемых необработанной строкой: является ли показанный порт явным или по умолчанию схема, и является ли хост именованным доменом или RAW IP.
В чем разница между именем хоста, хостом и происхождением?
Эти трое постоянно сбивают людей с толку, и путаница вызывает настоящие ошибки - сбои CORS, ошибки определения объема файлов cookie, несоответствия перенаправления. Они не являются синонимами. The whatwg стандарт URL действительно ли браузеры реализуют определения, и это место, где можно урегулировать спор о том, что считается источником.
имя хоста это просто домен или ip: shop.example.co.uk, йо- Нет порта, нет схемы. Это то, что вы бы поместили в поиск DNS.
хозяин это имя хоста плюс порт, Но только когда порт присутствует в URL, йо- в связи с shop.example.co.uk:8443 Хост shop.example.co.uk:8443, йо- для равнины https://shop.example.co.uk/ Хост и имя хоста идентичны, поскольку порт 443 по умолчанию подразумевается, а не записывается. Это «только в моменте «правила» является тонкой, и поэтому один и тот же сайт может иметь два разных хоста.
происхождение Есть схема плюс хост: https://shop.example.co.uk:8443. Это тот, который браузеры заботятся о большинстве, потому что политика одного и того же происхождения - основа веб-безопасности - сравнивает происхождение, а не имена хостов. Два URL-адреса имеют общее происхождение только в том случае, если их схема, имя хоста, а Порт все совпадают. http://example.com а https://example.com имеют разное происхождение, потому что схема отличается. https://example.com а https://example.com:8443 являются разными, потому что порт отличается, хотя имя хоста одинаково. Если выборка не выполняется с ошибкой CORS, сравнение двух источников между ними в парсере обычно является самым быстрым способом обнаружить несоответствие.
Как разобрать строку запроса?
Строка запроса — это место, где живет большая часть повседневной боли, потому что это плоский, неэссятированный двоичный объект, который фактически структурирован и закодирован в процентах. Парсер делит его для вас: все после ?, сломанный &, с каждым key=value Пара декодирована и перечислена в таблице в исходном порядке.
Здесь имеют значение два поведения. в первую очередь декодирующий, йо- параметр, записанный как q=trail%20runner на проводе показано как trail runner В столбце Значение, т.к. %20 является пробелом в процентах. сырой search строка по-прежнему отображается нетронутой в списке компонентов, поэтому вы можете сравнить закодированную и декодированную формы, что неоценимо, если вы подозреваете двойное кодирование, как у меня %2520 Ошибка OAuth.
вторая, Повторные ключи, йо- URL-адрес может на законных основаниях нести один и тот же ключ более одного раза: ?tag=react&tag=typescript&tag=node.Многие наивные парсеры сворачивают их, сохраняя только первое или последнее значение и молча теряя данные. Это неправильно - повторяющиеся ключи - это то, как формы HTML отправляют поля с несколькими вариантами выбора и как многие API выражают массивы. Парсер сохраняет каждое вхождение как свою собственную строку, по порядку, поэтому вы видите все три тега. Когда вы копируете запрос как JSON, повторяющиеся ключи становятся массивом, который является формой, которую ожидает самый код.
Вам даже не нужен полный URL, чтобы использовать это Вставить только строку запроса - color=red&size=42 - и инструмент анализирует его самостоятельно. Это самый быстрый способ понять полезную нагрузку веб-крючка или ссылку для отслеживания, которую кто-то вам переслал.
Как использовать синтаксический анализатор URL?
Инструмент предназначен для того, чтобы уйти с вашего пути Вставить URL-адрес в единый вход, и он анализирует в реальном времени по мере ввода - нет кнопки для нажатия. образец ссылки предварительно загружен, чтобы вы могли увидеть полную разбивку сразу, и кнопка Очистить опустошает поле.
Не нужно печатать схему. Вставьте голый хост, как example.com/pricing и синтаксический синтакумент https:// автоматически, затем говорит вам, что это было сделано с небольшой заметкой, поэтому вы никогда не путаетесь, откуда взялась схема Вставить явную схему - http://, ftp://, ssh:// - и вместо этого он уважает это.
Выход имеет четыре зоны. В верхней части Нормализованный URL - каноническая форма, созданная браузером и движком #39;s, с кнопкой копирования, которая удобна для выявления тонких различий в нормализации. Ниже компоненты таблица, одна строка с помеченной строкой на каждую часть, каждая независимо копируемая. к тому же Сегменты пути, разбит на индексированные чипы, так что глубокий путь, как /api/v2/users/42/orders можно с первого взгляда разборчиво. Наконец Параметры запроса Таблица, декодированная и упорядоченная, с действием "copy as Json", которое превращает весь запрос в чистый объект.
Все работает в вашем браузере с использованием собственного движка URL. Это преднамеренный выбор: URL-адреса обычно содержат маркеры доступа, идентификаторы сеансов, подписанные параметры и внутренние имена хостов, и ни один из них не должен быть отправлен на сервер только для чтения. Ничто из того, что вы вставляете, не оставляет вашего устройства, и инструмент продолжает работать в автономном режиме. Это тот же подход к конфиденциальности, который стоит за всем набором инструментов, который я изучаю в Руководство по набору инструментов для разработчиков веб-разработчика, йо-
Когда я могу связаться с парсером URL?
В моей собственной работе снова и снова возникают несколько ситуаций. Отладка перенаправлений и обратных вызовов это большой - потоки OAuth, URL-адреса возврата платежей, рукопожатия SSO, все из которых терпят неудачу при крошечных несоответствиях, которые становятся видимыми только тогда, когда вы разлагаете оба URL-адреса. Ссылки для отслеживания аудита Другое дело: маркетинговые URL-адреса часто представляют собой базовую страницу плюс дюжину параметров UTM и AD-платформы, а чтение их как таблица бьет щурение при 300-символьной строке. Если вы строите эти ссылки, а не читаете их, УТМ-строитель это вторая половина того же рабочего процесса.
Тогда есть API работа - проверка параметров запроса, фактически отправленного клиентом, или реверс-инжиниринг того, как конечная точка ожидает своих фильтров. и проверка безопасности: незнакомая ссылка в электронном письме или журнале гораздо безопаснее для понимания путем анализа его частей (какой хост делает это действительно указать на это имя хоста ip?), чем щелкнув по нему. Парсер раскрывает истинное имя хоста и помечает host-host-hosts, что является именно той информацией, которую вы хотите, прежде чем доверять ссылке. Я писал больше о сборке такого рода инспекционного комплекта в Руководство по инструментам отладки API, йо-
Как синтаксический анализ связан с кодированием и slugs?
Парсер URL-адресов — это один из уголков небольшого семейства инструментов ссылки, и знание того, какой из них вам нужен, экономит время. разбор чтение существующий URL и разбирает его. кодирующий делает противоположное направление на уровне символов - превращает пробелы и специальные символы в их формы с процентным кодированием, чтобы они выживали внутри URL-адреса, и обратно Когда вам нужно безопасно встроить значение в строку запроса, или декодировать то, что искажено, то есть кодер/декодер URL, и он естественным образом сочетается с парсером: синтаксический анализ Чтобы увидеть структуру, кодировать для исправления сломанного значения.
Slug поколение это третья, связанная работа - взять человеческое название, как & quot;10 Советы для более быстрого сборки & quot; и превратить его в чистоту 10-tips-for-faster-builds Сегмент пути. это то, что Slug Генератор Ручки, и это то, что производит аккуратность path компонент, который парсер позже считывает. представьте себе как конвейер: slugify для построения хороших путей, кодирование для обеспечения безопасности URL-адресов значений, анализ для проверки готовой ссылки. каждый инструмент выполняет одну часть жизненного цикла URL-адреса и делает это в браузере.
Как насчет IP-адресов и интернациональных доменов?
Не каждый хозяин аккуратный example.com, йо- Некоторые URL указывают на необработанные IP-адреса, и синтаксический анализатор распознает обе формы. буквальный IPv4, как http://192.168.1.10:3000/ имеет имя хоста 192.168.1.10, и инструмент помечает его как IP, а не домен - полезно, когда вы проверяете ссылку и хотите мгновенно узнать, нацелена ли она на именованный сайт или на голый адрес, что является распространенным сигналом в подозрительных ссылках. литералы IPv6 заключены в квадратные скобки в URL-адрес, как в http://[2001:db8::1]:8080/, а скобки являются частью синтаксиса узла, а не декоративными; синтаксические ручки правильно сформировали, а не засорялись двоеточиями, которые в противном случае выглядели бы как разделители портов.
Интернационализированные доменные имена - это другой крайний случай. Хост, написанный символами, отличными от ASCII (например, домен с акцентированными или нелатинскими буквами), преобразуется браузером и URL-движком #39;s в свой Punycode xn-- Форма для фактического запроса, потому что DNS говорит только на ASCII. Видя нормализованный href В парсере показано, что именно решит браузер, что время от времени удивляет людей, которые ожидали, что их красивый домен Unicode будет путешествовать без изменений. Для домена верхнего уровня синтаксический анализатор извлекает окончательную метку именованного узла, поэтому shop.example.co.uk сообщает о TLD uk. Это намеренно простое правило: оно не пытается отменить выбор многочастных суффиксов, например .co.uk в регистрируемый домен, потому что для этого требуется список суффиксов общедоступных, который представляет собой большой набор движущихся данных. Для быстрого осмотра последняя метка — это полезный сигнал, а для чего-то более строгого вы можете добраться до специальной библиотеки.
Рабочий пример связывает его вместе. Скажем, поставщик платежей продолжает отклонять ваш URL-адрес возврата. вы зарегистрировали https://app.example.com/checkout/return Но неудачный запрос показывает https://app.example.com:443/checkout/return/, йо- Разобрать оба. Парсер показывает, что у первого есть хост app.example.com (порт по умолчанию, нет слеша на пути) а у второго есть хост app.example.com тоже - но его путь есть /checkout/return/ с скользящей косой чертой, и его порт был написан явно как :443, йо- Два отличия, которые скользит глаз, оба фатальные по сравнению с точной совпадением. Как только вы сможете увидеть их как отдельные компоненты с меткой, исправление очевидно: нормализовать конечный косую черту и отбросить лишенный явный порт.
Распространенные ошибки при чтении URL
Повторяющиеся ошибки стоит назвать. путать фрагмент с путем или запросом - все после # является фрагментом, он полностью обрабатывается браузером и никогда не отправляется на сервер, поэтому параметр, который вы поставите после # не дойдет до вашего бэкэнда. Предполагая, что отсутствующий порт означает, что нет порта - пропущенный порт означает схему невыполненный (443 для https, 80 для http), который синтаксический анализатор делает явным, чтобы вы знали, какой порт действительно попадет.
Игнорирование двойного кодирования - если значение выглядит так %2520 вместо %20, он был закодирован дважды; разобрать его, и если декодированное значение все еще содержит процентную последовательность, снова декодируйте. Доверяем видимый текст ссылки - текст, который вы видите, и фактический href Может полностью отличаться, что является целым механизмом фишинга; разбор показывает реальный хост назначения. а Обработка повторяющихся ключей запросов как дубликатов для отбрасывания - это часто значимые массивы, и их удаление приводит к потере данных.
Часто задаваемые вопросы
Какие части URL?
URL имеет схему (https), необязательные учетные данные (user:pass@), хост (example.com) с необязательным портом, путь (/blog/post), необязательная строка запроса (?id=42) и необязательный фрагмент (#раздел). Этот парсер разделяет и маркирует каждый из них.
Как разобрать строку запроса?
Вставьте полный URL-адрес и прочитайте таблицу запросов или вставьте только строку запроса. Парсер делит его на амперсанды, декодирует кодирование процента и перечисляет каждую пару ключ-значение по порядку. Повторяющиеся ключи, такие как TAG=A&tag=b, сохраняются как отдельные строки.
В чем разница между именем хоста, хостом и происхождением?
Имя хоста — это только домен или ip (example.com). Хост добавляет порт, когда он присутствует (example.com: 8443). Origin — это схема плюс хост (https://example.com: 8443) и это то, что браузеры используют для проверки безопасности того же происхождения.
Какой порт используется, когда URL-адрес не имеет номера порта?
Схема решает. HTTPS по умолчанию 443, HTTP до 80, SSH до 22 и FTP до 21. Этот синтаксический анализатор показывает эффективный порт и помечает его как значение по умолчанию, поэтому вы знаете, какой порт действительно будет использовать запрос.
Декодирует ли парсер с процентными кодами?
Да, для значений запроса. Параметр, подобный имени=John%20DOE, отображается в таблице как "John Doe". Строка поиска также отображается нетронутой, поэтому вы можете сравнить закодированные и декодированные формы.
Могу ли я разобрать URL-адрес, не вводя часть HTTPS?
да. Если вы вставляете голый хост или путь, например, example.com/priceing, синтаксический анализатор автоматически добавляет https:// и отмечает, что он принял схему. Вставьте схему явно, например, http:// или ftp://, чтобы переопределить это предположение.
Почему мой URL не может разобрать?
Обычно хост отсутствует или неверно формируется, схема пишется неправильно, или строка содержит символы, которые являются незаконными в URL-адресе и не кодируются процентами. Проверьте пробелы, неэкранированные скобки или недостающие косые черты после схемы.
Безопасно ли вставлять URL-адреса с токенами или идентификаторами сеансов?
да. Разборка выполняется полностью в вашем браузере с использованием своего собственного движка URL. Ссылка никогда не отправляется на сервер, никогда не заходила и никогда не сохранялась, поэтому URL-адреса, содержащие маркеры доступа, ключи API или внутренние имена хостов, остаются на вашем устройстве.
