URL і кодування

З яких частин складається URL і за що відповідає кожна?

Повний URL — це scheme://user:password@host:port/path?query#fragment. Схема визначає протокол і правила гри (як з'єднуватися, який порт типовий), userinfo — дані для Basic Auth, хост — ім'я чи IP сервера, порт — число після двокрапки, path — шлях до ресурсу в межах сервера, query — параметри після ?, fragment — якір чи стан клієнта після #. Частина user:password@host:port разом називається authority. Сильний кандидат ще додасть, що не всі схеми мають authority: mailto:qa@example.com обходиться без //, а file:///... — зазвичай без хоста. Для тестувальника кожна частина — окрема зона відповідальності: схема й хост визначають безпекову межу, path і query — маршрутизацію, fragment живе тільки в браузері.

Що з URL реально передається на сервер, а що ні?

На сервер як «дані запиту» їдуть тільки path і query — вони формують ціль запиту (request-target): GET /catalog/phones?sort=price HTTP/1.1. Scheme, host і port використовуються, щоб встановити з'єднання, — куди й як під'єднатися; хост окремо дублюється в заголовку Host. Userinfo перетворюється на заголовок Authorization, а не летить у рядку запиту. Fragment на сервер не передається взагалі — його обробляє виключно браузер. У HTTP/2 і HTTP/3 замість рядка запиту — псевдозаголовки :path та :authority, але суть та сама: фрагмент і туди не потрапляє. Практичний наслідок: у серверних логах не буде слідів стану після #, а матчери перехоплення мережі можуть спиратися лише на path і query.

Що буде, якщо не вказати порт в URL?

Візьметься типовий порт схеми: 80 для http і ws, 443 для https і wss, 21 для ftp. Якщо порт збігається з типовим, при нормалізації він зникає: https://example.com:443/ і https://example.com/ — один і той самий ресурс, і об'єкт URL віддасть порожній port. А от нестандартний порт лишається і, головне, входить в origin: https://example.com:8443 — це вже інше джерело. Для тестів це означає, що асерт на url.port для типового порту має очікувати порожній рядок, а не '443'.

Що таке фрагмент і чому клік по якірному посиланню не породжує мережевого запиту?

Фрагмент — усе після #: історично якір на елемент з відповідним id, у сучасних SPA — стан клієнтського роутінгу (hash-routing виду #/dashboard/users). Він ніколи не йде на сервер, тому перехід #reviews → #specs обробляється повністю на клієнті через hashchange або History API — сторінка не перезавантажується і жодного запиту не виникає. Для автотестів це класична пастка: якщо тест чекає на мережевий запит після кліку по якірному посиланню, він зависне, бо запиту просто не буде. Правильне очікування тут — зміна DOM або URL, а не мережі. І дзеркальний висновок: у page.route чи проксі матчити по фрагменту неможливо — його немає в запиті.

Що таке origin і чому http://site.com та https://site.com — різні джерела?

Origin — це трійка «схема + хост + порт», і політика одного джерела (same-origin policy) розводить різні origin по ізольованих «пісочницях». http://site.com і https://site.com відрізняються схемою, отже це різні джерела, хоч хост однаковий. Так само різними джерелами будуть https://site.com і https://site.com:8443 — через порт. Для тестів наслідки прямі: web storage (localStorage/sessionStorage) ізолюється по origin, тож сервіси на різних портах одного хоста мають окремі сховища. А ще схема визначає безпекову межу: cookie з атрибутом Secure не поїде по http, а mixed content (коли https-сторінка тягне http-ресурс) браузер блокує чи примусово підвищує — і тест «незрозуміло чому» не бачить ресурс.

Що таке percent-encoding і як кодуються неASCII-символи, наприклад кирилиця?

URL за специфікацією може містити лише обмежений набір ASCII-символів, тому все інше кодується percent-encoding'ом: байт замінюється на % і два шістнадцяткові символи його значення. Ключовий механізм — двоетапний: спершу текст кодується в байти (для веб це майже завжди UTF-8), потім кожен байт окремо переписується як %XX. Пробіл — один байт 0x20, тому стає %20; українська «і» в UTF-8 — два байти 0xD1 0x96, тому перетворюється на %D1%96. Сильний кандидат уточнить, що шістнадцяткові цифри регістронезалежні: %2F і %2f — той самий байт, при нормалізації їх зазвичай приводять до верхнього регістру. Для AQA це означає, що в трасі мережі кириличний параметр виглядає «байтовою кашею» — і порівнювати треба декодовані значення, а не сирі рядки.

Які символи в URL потрібно кодувати, а які — ні?

Символи діляться на три категорії. Незарезервовані (A–Z a–z 0–9 - . _ ~) не потребують кодування ніколи. Зарезервовані (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) мають структурну роль — це роздільники: / ділить сегменти шляху, ? починає query, & і = ділять пари параметрів, # починає фрагмент — і кодуються тоді, коли їх треба вжити як дані, а не як роздільник. Усе інше (пробіли, неASCII, керівні символи) кодується завжди. Показовий приклад: пошуковий запит red & blue у параметрі мусить стати q=red%20%26%20blue, інакше незакодований & розірве значення на два параметри — і тест отримає не той запит, який очікував.

Чому пробіл в URL іноді %20, а іноді +?

Бо існують дві різні угоди кодування, які застосовуються в різних місцях. %20 — загальне percent-encoding пробілу за RFC 3986, коректне будь-де в URL: у шляху, у query, деінде. + як пробіл — правило окремого формату application/x-www-form-urlencoded, яким серіалізуються HTML-форми; у ньому справжній плюс кодується як %2B. Тобто + означає пробіл тільки в контексті form-urlencoded query, а в шляху + — це літеральний плюс. Сервер, який приймає form-urlencoded, декодує + назад у пробіл, тому q=search+results і q=search%20results логічно однакові — але як рядки не збігаються. Звідси правило для асертів: декодуй обидві сторони і порівнюй значення, а не сирі рядки, інакше тест залежатиме від того, хто і як закодував запит.

Чим відрізняються encodeURI та encodeURIComponent і коли яку функцію брати?

encodeURIComponent кодує все, крім невеликого списку безпечних символів, і призначена для одного компонента — значення параметра чи сегмента шляху. encodeURI лишає незакодованими структурні роздільники (: / ? # @ & = + $ , ;) і призначена для цілого URL, у якого структура вже правильна. Пастка в тому, що для окремого значення encodeURI небезпечна: encodeURI('https://s.com/?q=red & blue') лишить & як роздільник, і значення розпадеться на два параметри. Третій гравець — URLSearchParams: він складає і розбирає query, але кодує пробіл як +, а не %20. Тобто одне значення red & blue трьома інструментами дає три різні рядки. Правило просте: для окремого значення — завжди encodeURIComponent; для роботи з query цілком — URLSearchParams; а encodeURI — лише для вже структурно готового URL.

Чому decodeURIComponent('a+b') повертає a+b, і як правильно декодувати query-значення?

Бо decodeURIComponent реалізує тільки percent-decoding за RFC 3986 і нічого не знає про form-urlencoded-угоду, де + означає пробіл, — тому лишає плюс плюсом. А от парсер new URLSearchParams('q=a+b').get('q') поверне 'a b', бо він працює саме за правилами form-urlencoded. Симетрично і в інший бік: url.searchParams.set('q', 'a b') дасть у рядку q=a+b, тоді як об'єкт URL для шляху використовує %20. Правильний підхід — декодувати query-значення через URLSearchParams, а не через decodeURIComponent. У Playwright це виглядає так: у page.route береш new URL(route.request().url()) і порівнюєш url.searchParams.get('q') з людським текстом — метод сам декодує і %XX, і +. Ця плутанина регулярно народжує баги в URL-асертах і в підготовці тестових даних.

Чим абсолютний URL відрізняється від відносного і які типи відносних посилань бувають?

Абсолютний URL містить схему й достатньо інформації, щоб знайти ресурс без жодного контексту: https://shop.example.com/cart. Відносний набуває сенсу лише відносно базового URL і добудовується до абсолютного за правилами резолвінгу з RFC 3986. Типів кілька: відносний шлях (item.html, ../cart) заміщує останній сегмент шляху бази; абсолютний шлях (/help) — увесь шлях від кореня хоста; protocol-relative (//cdn.com/app.js) бере з бази лише схему; ?page=2 замінює тільки query; #top — тільки фрагмент. Базовий URL документа — це адреса, з якої сторінку завантажено, але його можна перевизначити тегом base у head, а в Playwright базу задає конфіговий baseURL. Для передбачуваності в тестах зазвичай беруть шляхи від кореня (/...) — вони не залежать ні від слеша, ні від поточної адреси.

Як резолвиться відносний шлях і чому завершальний слеш у baseURL критичний?

Правило: береться шлях бази, від нього відкидається все після останнього /, і на це місце підставляється відносний шлях — «файлова» частина бази викидається. Тому база https://s.com/catalog/phones/ плюс item.html дає https://s.com/catalog/phones/item.html, а база без слеша https://s.com/catalog/phones — уже https://s.com/catalog/item.html: сегмент phones сприйнято як «файл» і відкинуто. У Playwright page.goto з відносним аргументом резолвиться через той самий механізм new URL(arg, baseURL) — саме тому baseURL зі шляхом прийнято закінчувати слешем. Окремо треба розрізняти дві бази: браузер резолвить клік по посиланню відносно URL документа, а Playwright резолвить аргумент goto відносно конфігового baseURL, незалежно від того, де зараз стоїть сторінка. Плутанина між цими двома базами — типова причина «переходу не туди».

Які частини URL чутливі до регістру і як це впливає на автотести?

Scheme і host — нечутливі: HTTPS://SHOP.Example.COM/ нормалізується до https://shop.example.com/. Path, query і fragment — чутливі за специфікацією, але для path слово «фактично» критичне: реальна поведінка залежить від сервера й файлової системи. На Linux /Report.pdf і /report.pdf — різні файли, і промах у регістрі дасть 404; на Windows/IIS і в багатьох CDN обидва варіанти ведуть на той самий ресурс; а деякі сервери нормалізують регістр редіректом /Catalog → /catalog. Для тестів висновок такий: хардкодити регістр схеми й хоста в асертах безпечно, а порівнювати path «в лоб» ризиковано — тест може зеленіти на одному сервері й падати на іншому, і це неочевидний чинник флаку при переїзді локально → CI → stage. Якщо в трасі мережі несподіваний 301/308 одразу після навігації — спершу перевір регістр і завершальний слеш у path, це дешевша гіпотеза, ніж «сервер тупить».

Як працює user:password@ в URL і чому так робити не варто?

Ця частина задає облікові дані для HTTP Basic Authentication: браузер кодує їх у Base64 і формує заголовок Authorization, а не передає у відкритому вигляді в рядку запиту. Коли креденшели явно вказані в URL, браузер, як правило, шле заголовок превентивно — з першим запитом, не чекаючи на 401; втім, це залежить від клієнта, частина спершу пробує без авторизації, і це за хвилину перевіряється в DevTools. Синтаксис активно не рекомендують: пароль засвічується в історії й логах, його експлуатують для фішингу (тому браузери ховають цю частину в адресному рядку), а для підресурсних запитів сучасні браузери такі креденшели взагалі блокують. У тестах хардкодити креденшели в URL не варто — у Playwright для Basic Auth є окрема опція httpCredentials, яка робить те саме коректніше і бере пароль з env-змінної.

Чому асерт «поточний хост дорівнює приклад.укр» може провалитися?

Бо доменні імена не використовують percent-encoding: неASCII-домени кодуються окремим механізмом — Punycode (RFC 3492) в рамках IDNA. Домен приклад.укр браузер перетворює на ASCII-форму виду xn--..., і саме її повернуть API браузера — наприклад, url.hostname. Око бачить кирилицю в адресному рядку, а тест порівнює punycode-рядок з кириличним очікуванням і падає. Рішення — або очікувати punycode-форму, або нормалізувати обидві сторони до одного вигляду перед порівнянням. Це той випадок, коли «баг» насправді сидить в асерті, а не в застосунку.

Чим редіректи 301/302 небезпечніші за 307/308 у контексті тестів?

На редіректах 301/302 браузер може перетворити POST на GET і втратити тіло запиту, тоді як 307/308 зберігають і метод, і тіло. Типові генератори таких редіректів — дрібниці в path: завершальний слеш (/catalog/phones проти /catalog/phones/ сервер може вважати різними адресами й редіректити, типово 301 або 308 залежно від фреймворка) і регістр (/Catalog → /catalog). Кожен зайвий редірект — додатковий раунд очікування, тому тест, який «іноді падає на повільному кроці навігації», часто впирається саме в прихований редірект. Діагностика проста: відкрити трасу мережі й подивитися, чи немає 3xx одразу після навігації, а потім звірити слеш і регістр у шляху.

Чи ізолює нестандартний порт стан між тестами?

Частково — і саме ця асиметрія підступна. Порт входить в origin, тому web storage (localStorage/sessionStorage) на https://host:8443 і https://host:9443 — два окремі контексти. А от cookie порт не ізолює: за RFC 6265 порт не входить у scope cookie, розмежування йде лише по домену, шляху й (для Secure) схемі — тож сервіси на різних портах одного хоста ділять cookie. Практичний наслідок для тестів: паралельні стенди на різних портах одного хоста можуть «протікати» один в одного сесійними cookie, хоча localStorage у них розділений. Якщо тест на одному стенді раптом бачить сесію іншого — перше, що варто перевірити, чи не живуть обидва на одному хості з різними портами.

Чим RFC 3986 відрізняється від WHATWG URL Standard і де ця різниця стріляє?

RFC 3986 — базовий документ, що описує формальну граматику URI, а браузери реалізують живий стандарт WHATWG URL Standard, який у деталях від RFC відрізняється — наприклад, у поводженні з зайвими символами та нормалізації. Об'єкт URL у JavaScript і рядок в адресному рядку живуть за WHATWG, а серверна бібліотека на Python чи Java може розбирати той самий URL трохи інакше. Розбіжності на стиках клієнт–сервер — класичне джерело багів: обидві сторони «праві» за своєю специфікацією, але бачать різні результати парсингу. Сюди ж лягає внутрішня структура query: RFC визначає лише, що query — це все між ? і #, а розбиття на пари ключ=значення через & — домовленість від HTML-форм (історично роздільником подекуди був ;), тож сервер теоретично може парсити query як завгодно. Для AQA висновок: не покладатися, що всі учасники ланцюжка розберуть URL однаково, і в спірних місцях звіряти саме розібрані компоненти на кожній стороні.

Три кейси, де URL перестає бути «просто текстом»: розклад адреси на частини в DevTools із перевіркою, що фрагмент на сервер не йде; матч мережі по значенню параметра замість сирого рядка (пастка %20 vs +); і резолвінг відносного goto через baseURL, де завершальний слеш вирішує все. Скрізь — що дивитися і чому.

Кейс 1. Розкладаєш URL на частини — і «магія» зникає

Тест чекає на мережевий запит після кліку по якірному посиланню й зависає до таймауту. Перш ніж лізти в код, розклади URL на компоненти прямо в консолі DevTools — об'єкт URL зробить нормалізацію за тебе й покаже, що куди йде.

const u = new URL('HTTPS://SHOP.Example.COM:443/Catalog/phones?sort=price&page=2#reviews');
u.protocol;      // 'https:'  — схема опущена в нижній регістр
u.hostname;      // 'shop.example.com'  — хост теж нормалізовано
u.port;          // ''  — 443 типовий для https, тому зник
u.pathname;      // '/Catalog/phones'  — регістр і слеш ЗБЕРЕЖЕНО як є
u.searchParams.get('sort'); // 'price'
u.hash;          // '#reviews'  — живе лише тут, на сервер не піде

Що дивитися і чому:

• protocol і hostname — у нижньому регістрі. Схема й хост регістронезалежні й нормалізуються, тому асерт на них хардкодити безпечно. А от pathname лишився /Catalog з великої — path за специфікацією чутливий до регістру, і на Linux-сервері /Catalog та /catalog це різні ресурси (промах → 404 або несподіваний 301/308).
• port порожній. Типовий порт схеми в нормалізованому URL зникає: https://host:443/ і https://host/ — один ресурс. Якби порт був 8443, він лишився б і дав би інше джерело (origin = схема + хост + порт).
• hash тримається тільки в об'єкті URL. Фрагмент ніколи не летить на сервер: перехід #reviews → #specs не породжує нового HTTP-запиту, його обробляє браузер (hashchange/History API). Ось чому тест, що чекає на мережу після кліку по #-посиланню, зависає — запиту просто немає. Тут потрібне очікування зміни DOM/URL, а не мережі.

Реальний запит підтверджує це буквально — curl -v покаже рядок запиту без фрагмента:

curl -v 'https://shop.example.com/Catalog/phones?sort=price&page=2#reviews' 2>&1 | grep '^> GET'

> GET /Catalog/phones?sort=price&page=2 HTTP/1.1

У request-target є path і query — а #reviews немає ніде. Сервер фізично не знає про фрагмент, тож і в серверних логах його слідів не шукай.

Кейс 2. Матч мережі: пробіл як %20 чи + ламає порівняння рядків

Перехоплення (page.route) не спрацьовує на пошуковому запиті з пробілом чи кирилицею, хоча URL «на око» правильний. Причина — дві різні угоди кодування пробілу: %20 (загальний percent-encoding) і + (формат application/x-www-form-urlencoded, яким серіалізуються форми). Той самий запит різні збирачі закодують по-різному:

encodeURIComponent('кава з молоком');                       // '%D0%BA%D0%B0%D0%B2%D0%B0%20%D0%B7%20...' — кирилиця байтами, пробіл %20
new URLSearchParams({ q: 'кава з молоком' }).toString();    // 'q=%D0%BA...+%D0...'  — пробіл як +

Якщо матчиш по сирому рядку ?q=...%20..., а застосунок відправив +, збіг не спрацює — хоч значення логічно однакове. Плюс порядок параметрів у рядку теж може відрізнятися. Рішення — матчити по розібраному значенню, а не по сирому URL:

test('мок пошуку не залежить від кодування пробілу', async ({ page }) => {
  await page.route('**/api/search**', (route) => {
    const url = new URL(route.request().url());
    // searchParams.get сам декодує і %20, і + у людський текст
    if (url.searchParams.get('q') === 'кава з молоком') {
      return route.fulfill({ contentType: 'application/json', body: '{"items":[]}' });
    }
    return route.continue();
  });

  await page.goto('/search');
  await page.getByRole('searchbox').fill('кава з молоком');
  await page.getByRole('button', { name: 'Знайти' }).click();
  await expect(page.getByText('Нічого не знайдено')).toBeVisible();
});

Що дивитися і чому:

• searchParams.get('q') повертає людський текст. Він декодує і %D0%BA..., і +, тож у коді ти порівнюєш 'кава з молоком', а не байтову кашу. Умова стійка до того, хто і як закодував запит.
• Не пиши if (route.request().url().includes('q=кава%20з...')). Сирий рядок прив'язує тебе до конкретного кодування пробілу й порядку параметрів — класичне джерело «мок не спрацював».
• decodeURIComponent тут не помічник. Він нічого не знає про form-urlencoded: decodeURIComponent('a+b') віддасть 'a+b', а не 'a b'. Декодувати query-значення треба саме через URLSearchParams.

Кейс 3. Відносний goto і завершальний слеш у baseURL

Тест «переходить не туди»: page.goto('item.html') веде на несподівану адресу. Причина — правило резолвінгу відносного шляху з RFC 3986: береться baseURL, від нього відкидається все після останнього /, і на це місце стає відносний шлях. Завершальний слеш вирішує все.

// playwright.config.ts
export default defineConfig({
  use: { baseURL: 'https://shop.example.com/catalog/phones' }, // БЕЗ слеша в кінці
});

test('резолвінг залежить від слеша в baseURL', async ({ page }) => {
  await page.goto('/cart');       // → https://shop.example.com/cart      (шлях від кореня — слеш не важить)
  await page.goto('item.html');   // → https://shop.example.com/catalog/item.html  ← 'phones' відкинуто!
});

Якби baseURL закінчувався слешем (.../catalog/phones/), той самий item.html дав би .../catalog/phones/item.html. Саме тому baseURL зі шляхом прийнято закінчувати слешем.

Що дивитися і чому:

• Playwright резолвить відносний goto від конфігового baseURL, а не від поточної сторінки. Це інша база, ніж у браузера (той бере URL документа або <base href>). Плутати ці дві бази — типова причина «переходу не туди».
• Абсолютний від кореня шлях (/cart) не залежить ні від слеша, ні від поточної адреси. Для передбачуваності в тестах беруть саме такі шляхи, а не відносні item.html.
• Несподіваний 301/308 одразу після навігації — перша підозра на завершальний слеш або регістр у path (/Catalog → /catalog). Кожен зайвий редірект — це додатковий раунд очікування, звідки й береться «повільний» флакі-крок. Це дешевша гіпотеза, ніж «сервер тупить».

Окремо про Basic Auth: креденшели в URL (https://user:pass@host) у тестах не хардкодь — вони засвічують пароль у логах, а браузери блокують їх для підресурсних запитів. У Playwright для цього є httpCredentials, що робить те саме коректніше:

// playwright.config.ts — замість https://admin:secret@host у goto()
use: {
  httpCredentials: { username: 'admin', password: process.env.BASIC_PASS },
}

Анатомія URL

• Можу розкласти URL на частини scheme://user:password@host:port/path?query#fragment і назвати роль кожної, а authority — як хост із портом і опційним userinfo.
• Розумію, що origin — це схема + хост + порт, тому http://site.com і https://site.com (як і різні порти) — різні джерела; порт ізолює localStorage/sessionStorage, але cookie порт не ізолює (RFC 6265).
• Розумію, що типовий порт схеми (443 для https, 80 для http) при нормалізації зникає, тож https://example.com:443/ і https://example.com/ — той самий ресурс, а URL.port буде порожній.
• Можу пояснити userinfo (user:pass@): це креденшели для HTTP Basic Auth, які браузер кодує в Authorization, а не шле в query; у Playwright для цього є httpCredentials.
• Розумію, чому неASCII-домени кодуються Punycode (xn--...), а не percent-encoding, і що асерт «хост дорівнює приклад.укр» впаде, бо API поверне punycode-форму.

Що з URL іде на сервер

• Знаю, що на сервер ідуть path і query (як request-target), хост дублюється в Host, userinfo стає Authorization, а scheme/host/port лише встановлюють зʼєднання.
• Можу впевнено сказати: фрагмент (#...) на сервер не йде ніколи — його обробляє тільки браузер (скрол до id або hash-роутер), і в HTTP/2/3 через :path/:authority він теж не потрапляє.
• Розумію практичний наслідок: зміна лише фрагмента не породжує серверний запит (працюють hashchange/History API), тому тест, що чекає на мережу після кліку по якорю, зависне — чекати треба зміну DOM/URL.
• Знаю, що в перехопленні мережі не можна матчити по фрагменту (його немає в запиті) і що серверні логи його не бачать — баг стану після # шукаю на клієнті.

Percent-encoding

• Розумію механізм percent-encoding: текст спершу кодується в байти (для веб майже завжди UTF-8), потім кожен байт переписується як %XX (пробіл → %20, «і» U+0456 → %D1%96).
• Можу розвести unreserved (A–Z a–z 0–9 - . _ ~, ніколи не кодуються), reserved (структурні роздільники, кодуються коли треба вжити як дані) і решту (завжди кодується).
• Можу пояснити пастку пробілу: %20 — загальне правило RFC 3986 (валідне будь-де), а + — це пробіл тільки у форматі application/x-www-form-urlencoded; у шляху + — літеральний плюс.
• Знаю різницю трьох JS-функцій: encodeURIComponent (один компонент, пробіл → %20), encodeURI (лишає роздільники — небезпечний для значень, бо не кодує &), URLSearchParams (пробіл → +); і що decodeURIComponent НЕ перетворює + на пробіл.
• Можу сформулювати головне правило AQA: порівнюй декодовані значення, а не сирі рядки, і в перехопленні орієнтуйся на розібраний URL (searchParams.get), а не на байтову кашу.

Абсолютні й відносні URL

• Можу відрізнити абсолютний URL (самодостатній, зі схемою) від відносного (item.html, ../cart, /help, ?page=2, #top), який набуває сенсу лише відносно base URL.
• Розумію нюанс резолвінгу відносного шляху: від бази відкидається все після останнього / («файлова» частина), тому завершальний слеш у базі змінює результат.
• Можу розвести дві бази: браузер резолвить клік відносно URL документа (чи <base href>), а Playwright — goto через new URL(arg, baseURL) відносно конфігового baseURL, а не поточної сторінки; для передбачуваності беру абсолютні від кореня шляхи (/...).

Чутливість до регістру та нормалізація

• Знаю, що scheme і host регістронезалежні й нормалізуються в нижній регістр, а path, query і fragment — чутливі до регістру.
• Розумію, що «фактична» чутливість path залежить від сервера/ОС: Linux-ФС чутлива (промах у регістрі → 404), Windows/IIS і CDN часто ні, а дехто робить редірект /Catalog → /catalog.
• Можу пояснити, чому несподіваний 301/308 одразу після навігації — привід перевірити регістр і завершальний слеш у path (дешевша гіпотеза, ніж «сервер тупить»).
• Знаю, що шістнадцяткові цифри в percent-encoding регістронезалежні (%2F = %2f), і що це один із неочевидних чинників флаку при переїзді локально → CI → stage.