Lungimea maximă a unui URL: limita reală de caractere

Nu există o lungime maximă a URL-ului. RFC 3986, standardul care definește sintaxa URI, nu stabilește niciuna - descrie ce caractere sunt legale și cum se asamblează un URL, și se oprește acolo. Ce întâlnești de fapt este un lanț de limite separate, fără legătură între ele: bara de adrese a browserului tău, serverul web de la celălalt capăt, proxy-ul aflat între ele, clientul de email în care cineva deschide linkul tău, sau codul QR pe care ești pe cale să îl tipărești. Fiecare aplică propriul plafon, iar lungimea maximă reală a unui URL este oricare dintre aceste plafoane este cel mai jos. Trimite un URL de 3.000 de caractere și s-ar putea să se afișeze perfect în Chrome, să fie respins de un server cu setările implicite, și să ajungă în Outlook rupt pe patru rânduri. Nimic din toate astea nu este un bug. Este consecința practică a unui standard care a tăcut deliberat în privința acestei probleme.

Din asta rezultă patru lucruri: ce spune și ce nu spune standardul, de unde vine celebrul număr de 2.083 de caractere și de ce tot apare în liste de verificare la ani după ce a încetat să conteze, limitele care chiar mușcă odată ce un link părăsește browserul, și ce faci cu un URL care a devenit prea lung. Pentru ce face un shortener cu toate astea pe fir, vezi cum funcționează serviciile de scurtare URL.

Ce spune de fapt RFC 3986 despre lungimea URL-ului

RFC 3986 definește sintaxa generică a URI-urilor - schemă, autoritate, cale, query, fragment - și tace complet în privința cât de lungă poate fi oricare dintre ele. Nu tace prin omisiune; tace prin proiectare. Gramatica din secțiunea 3 construiește un URI dintr-un set restrâns de reguli de producție, și nimic din aceste reguli nu limitează de câte ori se poate repeta o regulă. Un segment de cale poate avea un caracter sau o sută de mii, în ceea ce privește sintaxa. URL-urile lungi sunt URL-uri perfect legale.

Singura limită pe care RFC-ul chiar o impune este indirectă: componenta de autoritate a unui URL include un hostname, iar DNS-ul limitează un hostname complet calificat mult sub ceea ce permite gramatica URI - documentația de inginerie a Chromium plasează acel plafon la 253 de caractere în total, 63 per etichetă. Calea, query string-ul și fragmentul nu poartă nicio asemenea constrângere nicăieri în standard.

Asta este întreaga poveste din perspectiva standardului. Limita de caractere a URL-ului de care te lovești de fapt în practică vine din software-ul care citește URL-ul, niciodată din formatul URL-ului în sine.

De unde a venit 2.083, și ce fac browserele acum

Dacă ai văzut vreodată o recomandare despre lungimea URL-ului undeva, ea cita 2.083 de caractere. Numărul este real, dar aparține unui singur browser, unei singure ere și unei singure căi de cod. Biblioteca de rețea WinINET a Internet Explorer definea INTERNET_MAX_URL_LENGTH ca 2083 de caractere, iar propriul articol tehnic al Microsoft despre această limită notează că bara de adrese în sine era plafonată cu un caracter mai jos, la 2.047. Acel plafon a guvernat o mare parte din traficul web timp de peste un deceniu, așa că a devenit numărul pentru care toată lumea proiecta, iar obiceiul a supraviețuit browserului pe care îl descrie.

Browserele moderne nu funcționează așa. Documentația Chrome menționează o limită internă de 2 megabytes, impusă pentru a evita probleme de comunicare inter-proces, nu pentru a proteja un câmp din interfață, cu o constantă mult mai mică, în jur de 32 de kilobytes pe desktop, care limitează ce va afișa efectiv omnibox-ul. Firefox și Safari sunt la fel de generoase - niciunul nu se blochează la un URL nici pe departe atât de lung cât ai construi tu de mână. Nu am depanat niciodată o problemă reală de producție cauzată de un browser modern care refuză un URL lung. Fiecare bug de URL lung pe care l-am urmărit a început în aval de browser.

Limitele din lumea reală care chiar mușcă

Aliniază unde călătorește de fapt un URL și un tipar apare rapid: limita cea mai strictă este rareori cea din browser.

• Linia de request a serverului citește URL-ul ca parte a primei linii dintr-o cerere HTTP, iar acea linie are propriul buffer. Depășește-o și serverul nu îți analizează niciodată ruta - refuză conexiunea înainte ca măcar codul aplicației tale să ruleze.
• Clienții de email tratează depășirea diferit. Outlook rupe un URL lung în text simplu pe mai multe rânduri în loc să îl trunchieze, ceea ce e urât dar rămâne clicabil; unii clienți de webmail și gateway-uri de redirecționare sunt mai puțin iertători și taie linkul direct.
• Un link dintr-un mesaj text concurează cu corpul mesajului pentru același buget de caractere, iar linkurile pentru marketing prin SMS trăiesc într-un segment de 160 de caractere - doar un URL lung poate împinge un text de un segment în două, iar operatorii le facturează și le filtrează diferit.
• Un cod QR nu trunchiază un URL lung; devine pur și simplu mai dens. Cât de mare trebuie să fie un cod QR depinde direct de cât îi ceri să codifice, iar un URL încărcat cu parametri de tracking poate ridica un cod cu o versiune sau două, micșorând distanța de la care se mai scanează.
• Funcțiile de hyperlink din foile de calcul aplică propria limită fixă de caractere pentru argumentul link, mult sub un URL etichetat tipic, iar un link care o depășește eșuează pe tăcute - celula se afișează perfect, dar linkul în sine nu funcționează.
• Platformele de publicitate limitează câmpul URL-ului de destinație la o lungime fixă, aleasă de ele, o regulă de platformă mai degrabă decât una tehnică, iar un campaign manager află abia atunci când butonul de salvare respinge ceva ce un browser ar deschide fără nicio problemă.

Niciuna dintre aceste limite nu comunică cu celelalte. Un URL poate trece cu bine de linia de request a serverului tău și totuși să moară într-o foaie de calcul trei departamente mai încolo.

Limitele liniei de request pentru servere și proxy-uri

Cazul serverului merită o privire aparte, pentru că este cel care produce un cod de eroare real, nu doar un glitch cosmetic. 414 Request-URI Too Long este răspunsul pe care îl trimite un server atunci când refuză să proceseze o cerere pentru că URI-ul este mai lung decât este dispus să interpreteze - o limită de dimensiune a URL-ului aplicată câte un hop odată, de orice software citește linia de request în acea secundă.

Fiecare server și proxy din lanț aplică propria versiune a acestei limite. Directiva LimitRequestLine din Apache are implicit 8.190 de octeți pentru întreaga linie de request, ceea ce include metoda și versiunea protocolului, nu doar URL-ul în sine. nginx citește header-ele cererii într-un buffer fix controlat de large_client_header_buffers, implicit 8 kilobytes, iar o linie de request care nu încape primește un 414 înainte ca ruta ta să se potrivească vreodată. Load balancerele și CDN-urile din fața oricăruia dintre ele aplică adesea o a treia limită, separată, așa că un URL poate trece de setarea serverului tău de origine și totuși să fie respins cu un hop mai devreme.

Dacă nu controlezi fiecare hop, și peste o anumită dimensiune a companiei nimeni nu o face, mișcarea sigură este să proiectezi pentru cel mai strict standard comun, nu pentru cel mai generos pe care l-ai găsit într-un fișier de configurare.

Construirea propriului strat de redirecționare în loc să scrii de mână analiza cererilor este soluția plictisitoare, dar corectă, aici. API-ul Elido acceptă o destinație de orice lungime rezonabilă și returnează un link scurt care nu își schimbă niciodată dimensiunea, astfel încât plafonul liniei de request al unui server devine ceva ce configurezi o singură dată la edge, în loc de ceva pe care fiecare integrare trebuie să îl gestioneze pe cont propriu.

Cum măsori lungimea reală a unui URL înainte să îl trimiți

Numărul de caractere este toată măsurătoarea, și merită verificat înainte ca un URL să intre într-o campanie, nu după ce ajunge un raport de bounce.

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

Asta îți dă lungimea în octeți a URL-ului exact așa cum este scris. Două lucruri complică situația. Primul, caracterele codificate procentual costă mai mult decât par: o literă cu diacritice sau un emoji în interiorul unei valori din query se poate extinde la șase caractere sau mai mult odată codificat, așa că măsoară URL-ul după codificare, nu înainte. Al doilea, parametrii UTM sunt de obicei partea care crește cel mai rapid dintr-un URL - o mână de etichete de campanie, sursă, mediu și conținut pot adăuga câteva sute de caractere la ceea ce a început ca o cale scurtă, și sunt primul loc unde te uiți atunci când un URL a crescut pe tăcute prea mult.

Dacă un link care funcționa înainte se oprește brusc, rulează aceeași depanare pe care ai folosi-o pentru orice link mort: linkul scurt nu funcționează parcurge verificarea directă a destinației, exact modul în care ai prinde un URL care a crescut peste limita unui server câte un parametru de tracking odată.

Ce faci atunci când un URL este prea lung

Două soluții chiar funcționează, și sunt aceleași două indiferent de limita de care te-ai lovit.

Prima este să scurtezi URL-ul. Un link scurt este un pointer de lungime fixă - slug-ul rămâne aceeași lungime indiferent cât de mult cresc destinația sau parametrii ei de tracking, pentru că toate acestea trăiesc pe partea de server și sunt căutate la fiecare click, în loc să fie transportate în interiorul linkului în sine. Asta rezolvă dintr-o mișcare problema densității codului QR, problema segmentului SMS și problema foii de calcul, întrucât toate trei țin cont de numărul de caractere al linkului, nu de lungimea locului spre care indică în cele din urmă.

A doua este să muți starea complet în afara query string-ului. Dacă ce face URL-ul tău lung sunt datele de sesiune, un bloc cu conținutul unui coș de cumpărături sau o listă lungă de filtre, mai degrabă decât parametri de tracking autentici, acele date aparțin de obicei pe server, în spatele unui ID opac, nu scrise explicit în bara de adrese. Un URL care arată ca /checkout?session=a1b2c3d4 îmbătrânește mai bine decât unul care arată ca /checkout?items=... cu fiecare SKU și cantitate scrise integral, și ocolește dintr-odată fiecare limită din acest articol, pentru că nu mai rămâne nimic lung de măsurat.

Ambele soluții indică aceeași direcție: tratează lungimea unui URL ca pe o decizie de design, nu ca pe un accident al câți parametri s-au întâmplat să se acumuleze pe el.

Citește seria fundamentală

Acest articol face parte din clusterul engineering. Pentru ce se întâmplă la celălalt capăt al unui link scurt, cum funcționează serviciile de scurtare URL acoperă căutarea în sine, iar tipurile de redirecționări URL acoperă codurile de stare implicate odată ce destinația este găsită.

Alte articole de pe blog

• Codificarea URL explicată: ce caractere trebuie codificate
• Parametrii UTM explicați, cu o schemă de denumire care rezistă
• Cât de mare ar trebui să fie un cod QR? Reguli de dimensiune și distanță
• Shortener URL pentru marketing prin SMS în care operatorii au încredere
• Linkul scurt nu funcționează? Diagnostichează-l cu o singură comandă