URL виглядає як суцільний рядок тексту, але насправді складається з чітко визначених частин, кожна з яких має власне призначення й власні правила кодування символів.
Основні частини URL
- Протокол (scheme) —
https://, визначає спосіб з'єднання з ресурсом. - Хост —
example.com, доменне ім'я або IP-адреса сервера. - Порт — необов'язковий, за замовчуванням 443 для HTTPS і 80 для HTTP.
- Шлях (path) —
/articles/network, вказує на конкретний ресурс на сервері. - Рядок запиту (query string) — після
?, набір пар ключ-значення. - Фрагмент (hash) — після
#, вказує на частину сторінки.
Чому фрагмент ніколи не потрапляє на сервер
Частина URL після символу # обробляється виключно браузером — вона використовується, наприклад, для прокрутки до потрібного заголовка на сторінці. Ця частина ніколи не надсилається на сервер разом з HTTP-запитом, тож серверний код взагалі не бачить її значення.
Чому кодування символів у URL складне
Різні частини URL мають різні правила щодо того, які символи дозволені без екранування. Символ & у шляху безпечний, але в рядку запиту він розділяє пари параметрів, тож його потрібно кодувати як %26, якщо він є частиною значення, а не роздільником.
Навіщо це потрібно
- Розібрати складний URL на компоненти для налагодження або логування.
- Зрозуміти, чому певний параметр не потрапляє на бекенд.
- Побудувати коректний URL програмно, уникаючи помилок кодування.
Фішинговий трюк із userinfo
URL на кшталт https://accounts.google.com@evil.com/ виглядає так, ніби веде на accounts.google.com, але насправді браузер відкриє evil.com — частина до символу @ це лише логін (userinfo), а не хост. Зловмисники використовують цей трюк для маскування фішингових посилань під довірені домени, тому сучасні браузери намагаються візуально виділяти справжній хост, а деякі сервіси скорочення посилань взагалі забороняють userinfo в URL.