Максимальна довжина URL: реальне обмеження символів

Максимальної довжини URL не існує. RFC 3986 - стандарт, що визначає синтаксис URI, - ніде її не встановлює: він описує, які символи легальні і як складається URL, і на цьому зупиняється. Насправді ви натрапляєте на ланцюжок окремих, не пов'язаних між собою обмежень: адресний рядок вашого браузера, вебсервер на іншому кінці, проксі між ними, поштовий клієнт, у якому хтось відкриває ваше посилання, або QR-код, який ви ось-ось надрукуєте. Кожен із них застосовує власну межу, і реальна максимальна довжина URL - це найнижча з цих меж. Відправте URL завдовжки 3000 символів, і він може нормально відобразитися в Chrome, отримати відмову від сервера з налаштуваннями за замовчуванням і прийти в Outlook перенесеним на чотири рядки. Жодне з цього не є багом. Це практичний наслідок специфікації, яка свідомо мовчала з цього питання.

Звідси випливають чотири речі: що стандарт каже, а що ні; звідки взялося знамените число в 2083 символи і чому воно й досі зринає в чеклістах через роки після того, як перестало мати значення; обмеження, що насправді дошкуляють, щойно посилання покидає браузер; і що робити з URL, який виріс завеликим. Про те, що скорочувач робить з усім цим на практиці, читайте у статті як працюють скорочувачі URL.

Що RFC 3986 насправді каже про довжину URL

RFC 3986 визначає загальний синтаксис URI - схему, авторитет, шлях, запит, фрагмент - і мовчить про те, наскільки довгою може бути будь-яка з цих частин. Мовчить не через недогляд - мовчить навмисно. Граматика в розділі 3 будує URI з невеликого набору правил виведення, і жодне з цих правил не обмежує, скільки разів правило може повторитися. Із погляду синтаксису сегмент шляху може бути завдовжки в один символ або в сто тисяч. Довгі URL - цілком легальні URL.

Єдине обмеження, яке RFC усе-таки встановлює, - непряме: компонент авторитету URL включає ім'я хоста, а DNS обмежує повністю кваліфіковане ім'я хоста значно нижче того, що дозволяє граматика URI - інженерна документація Chromium встановлює цю межу в 253 символи загалом, по 63 на мітку. Шлях, рядок запиту і фрагмент не мають такого обмеження ніде в стандарті.

Це вся історія з боку специфікації. Обмеження довжини URL, на яке ви насправді натрапляєте на практиці, походить від програмного забезпечення, що читає URL, а не від самого формату URL.

Звідки взялося число 2083 і що роблять браузери зараз

Якщо ви десь бачили рекомендацію щодо довжини URL, вона цитувала число 2083 символи. Це число реальне, але воно належить одному браузеру, одній епосі й одному шляху коду. Мережева бібліотека WinINET Internet Explorer визначала INTERNET_MAX_URL_LENGTH як 2083 символи, і власний інженерний матеріал Microsoft про цю межу зазначає, що сам адресний рядок був обмежений на один символ менше - до 2047. Ця межа керувала величезною часткою вебтрафіку понад десятиліття, тож стала числом, на яке всі орієнтувалися, і звичка пережила браузер, який вона описує.

Сучасні браузери працюють інакше. Документація Chrome вказує внутрішню межу в 2 мегабайти, встановлену для уникнення проблем міжпроцесної комунікації, а не для захисту поля інтерфейсу, при цьому значно менша константа - приблизно 32 кілобайти на десктопі - обмежує те, що омнібокс справді покаже. Firefox і Safari так само щедрі - жоден із них не вдавиться URL завдовжки, яку ви, найімовірніше, зможете скласти вручну. Я жодного разу не налагоджував реальну продакшн-проблему, спричинену тим, що сучасний браузер відмовився приймати довгий URL. Кожен баг із довгим URL, який я відстежував, починався десь після браузера.

Реальні обмеження, що насправді дошкуляють

Вишикуйте місця, куди насправді подорожує URL, і закономірність виявляється швидко: найжорсткіше обмеження рідко належить браузеру.

• Рядок запиту сервера читає URL як частину першого рядка HTTP-запиту, а цей рядок має власний буфер. Перевищте його - і сервер узагалі не розбере ваш маршрут: він відхилить з'єднання ще до того, як код вашого застосунку взагалі запуститься.
• Поштові клієнти по-різному обробляють переповнення. Outlook переносить довгий URL у форматі звичайного тексту на кілька рядків, а не обрізає його, - виглядає негарно, але й далі клікабельно; деякі вебпоштові клієнти й шлюзи пересилання менш поблажливі та просто обрізають посилання.
• Посилання в текстовому повідомленні конкурує з тілом повідомлення за той самий бюджет символів, а посилання для SMS-маркетингу живуть у сегменті на 160 символів - самого лише довгого URL достатньо, щоб перетворити односегментний текст на два, а оператори тарифікують і фільтрують їх по-різному.
• QR-код не обрізає довгий URL - він просто стає щільнішим. Яким має бути розмір QR-коду напряму залежить від того, скільки ви просите його закодувати, а URL, перевантажений трекінговими параметрами, може підняти код на версію-другу вище, скорочуючи відстань, з якої він усе ще скануватиметься.
• Функції гіперпосилань у таблицях застосовують власну жорстку межу символів для аргументу посилання, значно коротшу за типовий URL із мітками, і посилання, що перевищує її, ламається мовчки - клітинка виглядає нормально, а саме посилання не працює.
• Рекламні платформи обмежують поле URL призначення фіксованою довжиною на власний розсуд - це правило платформи, а не технічне обмеження, - і менеджер кампанії дізнається про це лише тоді, коли кнопка збереження відхиляє те, що браузер відкрив би без жодних заперечень.

Жодне з цих обмежень не залежить від інших. URL може пройти рядок запиту вашого сервера і все одно відмовити в таблиці трьома відділами далі.

Обмеження рядка запиту на сервері та проксі

Випадок сервера заслуговує на окремий розгляд, бо саме він видає реальний код помилки, а не косметичний глюк. 414 Request-URI Too Long - це відповідь, яку сервер надсилає, коли відмовляється обробляти запит, бо URI довший, ніж він готовий інтерпретувати, - обмеження розміру URL, що застосовується по одному хопу за раз, тим програмним забезпеченням, яке читає рядок запиту в цю секунду.

Кожен сервер і проксі в ланцюжку застосовує власну версію цього обмеження. Директива Apache LimitRequestLine за замовчуванням дорівнює 8190 байтам для всього рядка запиту, що включає метод і версію протоколу, а не лише сам URL. nginx читає заголовки запиту у фіксований буфер, який контролюється директивою large_client_header_buffers, за замовчуванням 8 кілобайт, і рядок запиту, який туди не влазить, отримує 414 ще до того, як ваш маршрут взагалі співпаде. Балансувальники навантаження й CDN перед будь-яким із них часто застосовують третє, окреме обмеження, тож URL може пройти налаштування вашого origin-сервера і все одно отримати відмову на хоп раніше.

Якщо ви не контролюєте кожен хоп - а після певного розміру компанії цього не робить ніхто - безпечний хід полягає в тому, щоб проєктувати під найжорсткіше з поширених значень за замовчуванням, а не під найщедріше, яке ви знайшли в конфігураційному файлі.

Побудова власного шару редиректів замість самостійного розбору запитів - нудне, але робоче рішення. API Elido приймає адресу призначення будь-якої розумної довжини і повертає коротке посилання, яке ніколи не змінює розмір, тож межа рядка запиту сервера стає тим, що ви налаштовуєте один раз на межі мережі, а не тим, із чим кожна інтеграція має розбиратися самостійно.

Як виміряти реальну довжину URL, перш ніж його відправити

Кількість символів - це весь вимір, і його варто перевіряти до того, як URL потрапить у кампанію, а не після того, як прийде звіт про відмови.

printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c

Це дає вам довжину URL у байтах, точно в тому вигляді, у якому він написаний. Дві речі це ускладнюють. По-перше, символи, закодовані процентним кодуванням, коштують більше, ніж здається: літера з діакритикою чи емодзі всередині значення запиту може розширитися до шести й більше символів після кодування, тож вимірюйте URL після кодування, а не до. По-друге, UTM-параметри зазвичай є найшвидше зростаючою частиною URL - жменька міток campaign, source, medium і content може додати кілька сотень символів до того, що починалося як короткий шлях, і саме туди варто дивитися першим ділом, коли URL непомітно виріс завеликим.

Якщо посилання, яке раніше працювало, раптом перестало, проведіть таку саму перевірку, яку ви застосували б до будь-якого неробочого посилання: коротке посилання не працює розкриває, як перевірити адресу призначення напряму, - саме так ви виявите URL, що переріс межу сервера один трекінговий параметр за раз.

Що робити, коли URL завеликий

Насправді працюють два виправлення, і вони однакові незалежно від того, яке обмеження ви зачепили.

Перше - скоротити URL. Коротке посилання - це вказівник фіксованої довжини: слаг залишається такої самої довжини незалежно від того, наскільки виростає адреса призначення чи її трекінгові параметри, бо все це живе на боці сервера і підтягується під час кожного кліку, а не переноситься всередині самого посилання. Це вирішує проблему щільності QR-коду, проблему SMS-сегментів і проблему таблиць одним рухом, бо всі три залежать від кількості символів у посиланні, а не від довжини того, куди воно врешті-решт веде.

Друге - повністю винести стан за межі рядка запиту. Якщо ваш URL стає довгим через дані сесії, вміст кошика чи довгий список фільтрів, а не через справжні трекінгові параметри, ці дані зазвичай мають жити на боці сервера за непрозорим ідентифікатором, а не бути виписаними в адресному рядку. URL виду /checkout?session=a1b2c3d4 старіє краще, ніж /checkout?items=... з повністю виписаним кожним SKU і кількістю, і водночас він одразу обходить усі обмеження з цієї статті, бо там просто не залишається нічого довгого, що можна виміряти.

Обидва виправлення вказують в одному напрямку: ставтеся до довжини URL як до дизайнерського рішення, а не як до випадковості, породженої тим, скільки параметрів на ньому накопичилося.

Читайте наріжну серію

Цей матеріал належить до кластера engineering. Про те, що відбувається на іншому кінці короткого посилання, розповідає як працюють скорочувачі URL - там ідеться про сам пошук, - а типи редиректів URL охоплює коди статусу, задіяні після того, як адресу призначення знайдено.

Пов'язане в блозі

• URL-кодування пояснене: які символи екранувати
• UTM-параметри пояснені, зі схемою іменування, що не застаріває
• Яким має бути розмір QR-коду? Правила розміру й відстані
• Скорочувач URL для SMS-маркетингу, якому довіряють оператори
• Коротке посилання не працює? Діагностика однією командою