Cos'e HTTP 414 URI Too Long
Il codice HTTP 414 URI Too Long indica che l'URI inviato dal client supera la lunghezza massima accettata dal server. E un'errore tipico di applicazioni che generano URL dinamici con molti parametri in query string o di attacchi che tentano di bypassare validazioni con URI estremi.
Lunghezze tipiche dei server
| Software | Limite default URI |
|---|---|
| Apache (LimitRequestLine) | 8190 byte |
| Nginx (large_client_header_buffers) | 8KB per buffer (4 buffer) |
| IIS | 4096 caratteri (configurabile fino a 16384) |
| Tomcat (maxHttpHeaderSize) | 8KB |
| Node.js (max-http-header-size) | 16KB (default da v14) |
Lunghezze tipiche dei browser
- Chrome: 32KB nell'URL bar, ma RFC raccomanda < 2048.
- Firefox: 65KB.
- Safari: 80KB.
- Edge: 32KB (Chromium-based).
- IE11: 2083 caratteri (limite storico).
Per compatibilità massima e SEO, mantieni URL sotto 2048 caratteri.
Cause comuni di 414
- API GET con molti filtri concatenati in query string.
- URL con base64 di immagini, token JWT, payload JSON.
- Form HTML inviati come GET con dozzine di campi.
- Tracking parameter aggiunti da campagne pubblicitarie.
- Attacchi (URI bombing, buffer overflow attempt).
Configurazione Apache
LimitRequestLine 16384
LimitRequestFieldSize 16384Da inserire nel virtual host. Massimo consigliato: 32KB. Oltre apre la porta a DoS amplification.
Configurazione Nginx
http {
large_client_header_buffers 4 16k;
client_header_buffer_size 16k;
}Il primo numero (4) e quanti buffer; il secondo (16k) la dimensione di ciascuno. Il totale del header puo arrivare a 64KB.
Configurazione Node.js
node --max-http-header-size=32768 server.js
# oppure
const server = require('http').createServer({
maxHeaderSize: 32768
}, requestHandler);Soluzione: convertire GET in POST
La soluzione più robusta per richieste con molti parametri e usare POST con body JSON:
// Invece di:
GET /api/search?filters=a&filters=b&... (URL kilometrico)
// Usa:
POST /api/search
Content-Type: application/json
{
"filters": ["a", "b", "c", ...],
"sort": "date",
"page": 1
}Cookie e header lunghi
Il 414 puo essere causato anche da header molto grandi (non solo l'URL). Cookie di sessione enormi, header X-Forwarded-* in catene di proxy, JWT in Authorization possono saturare il buffer header.
Tracking e UTM excess
Le campagne marketing spesso aggiungono parametri UTM, fbclid, gclid, msclkid che gonfiano le URL. Best practice:
- Spostare logica di tracking lato client tramite JavaScript.
- Usare URL shortener per condividere link in canali con limiti (SMS, social).
- Memorizzare l'intera campaign info in cookie o localStorage, mandando ID compatti via URL.
SEO impact
Google ha confermato di indicizzare URL fino a 2048 caratteri. Oltre, l'indicizzazione potrebbe essere parziale o omessa. URL più corti sono inoltre più cliccabili nelle SERP e nei social.
Sicurezza
Limiti generosi di URI possono essere sfruttati per:
- DoS: invio massivo di URL enormi per saturare memoria.
- Log injection: URL costruite per polluire log file.
- WAF bypass: URL frammentate per evadere regole di pattern matching.
Mantieni i limiti ragionevoli (16-32KB max) e logga tentativi di URI molto lunghi come red flag.
Risposta del server
HTTP/1.1 414 URI Too Long
Content-Type: text/html
<html>
<head><title>414 Request-URI Too Long</title></head>
<body>
<h1>Request-URI Too Long</h1>
<p>The requested URL exceeds the server's maximum length.</p>
</body>
</html>Diagnostica
curl -v "https://example.com/api/search?$(printf 'q=test&%.0s' {1..1000})"Costruisce una URL artificialmente lunga per testare i limiti. Se ottieni 414, sai che il limite e attivo a qualche livello della catena.
Limiti GET e SEO
Google indicizza URL fino a 2048 caratteri. URL più lunghe possono essere truncate o non indicizzate. Per categorizzazione SEO, slug brevi e descrittivi sono preferiti: /blog/seo-2026 e meglio di /blog/categoria/?id=1234&name=seo-best-practices-2026&source=....
JWT in URL
Anti-pattern comune: passare JWT lunghi (1000+ caratteri) in query string per autenticazione magic-link. Risolvere con: short-lived token UUID memorizzato lato server, swap to JWT al primo touch. URL più corte, log più sicuri (no JWT esposto), revoca centralizzata.
Buffer overflow attacks
Server con buffer non protetto possono crashare ricevendo URI estremamente lunghe (es. milioni di caratteri). Protezione: limiti hard a livello di reverse proxy (es. Nginx 8KB) e WAF (Cloudflare, AWS WAF) prima ancora di toccare l'application server.
414 in PHP/Apache
PHP eredita i limiti di Apache. Se vedi 414 inspiegabili, controlla: LimitRequestLine in Apache, max_input_vars in PHP (default 1000 variabili), post_max_size per dati POST. Header eccessivi anche.
Mobile-first considerations
Le URL condivise via SMS o messaging app spesso vengono troncate. Mantenere URL pubbliche sotto 100 caratteri quando possibile. Per condivisione, usare URL shortener con il proprio dominio per branding.
Soluzioni per filtri estensivi
API di ricerca con filtri complessi spesso superano i limiti GET. Strategie:
- POST con body JSON: standard per API moderne con filtri ricchi.
- Encoded body: GET con singolo parametro
q=base64(json). Trasforma molte chiavi in una singola. - Saved filters: utente salva preset, accede con singolo ID.
API GraphQL
GraphQL risolve elegantemente il problema: query complesse vanno nel body POST. Anche con GET, e una singola variabile query che, per quanto lunga, sta nei limiti normali.
Limiti CDN
Cloudflare ha limiti su URL ricevuti: 8KB per default. Configurazioni Enterprise possono alzare a 32KB. Oltre, il CDN risponde 414 prima ancora di toccare la tua origin. Verifica con curl diretto vs via CDN.
Logging tentativi sospetti
URL artificialmente lunghi sono spesso indicatori di attacchi. Configura logging accentuato per URL > 4KB, alert su pattern ricorrenti. Combinato con WAF, blocca prima di consumare resource.
Hai bisogno di aiuto?
Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.