Ho perso un pomeriggio una volta a causa di un URL che sembrava a posto. Una richiamata OAuth continuava a fallire, il reindirizzamento URI "corrisponde" quello registrato con il provider e non riuscivo a capire perché la stretta di mano si fosse rotta. La risposta, quando finalmente ho incollato la cosa in un parser, è stata una barra finale sul sentiero in un posto e nessuno nell'altro, più un state parametro che era stato codificato in doppio %20 era diventato %2520. A occhio umano i due URL erano identici. Per il server OAuth erano stringhe diverse, ed era giusto rifiutare la mancata corrispondenza.
Questo è il problema con gli URL: sono densi, sono facili da leggere male e i dettagli che interrompono le cose - una barra codificata, una porta vagante, una chiave di query ripetuta, un frammento in cui ti aspettavi un percorso - sono esattamente quelli che nascondersi in un muro di caratteri Costruisco [Toolz.dev](/, e passo abbastanza tempo a fissare le stringhe di query durante il debug da creare un Parser URL per fare lo sguardo per me. Incolla un collegamento, ottieni ogni componente etichettato e ogni parametro di query decodificato in una tabella. Questa guida spiega quali sono questi componenti, perché le distinzioni contano e come usarle.
tl; dr: Un URL è costituito da uno schema (
https), credenziali facoltative (user:pass@), un host (example.com) con una porta opzionale, un percorso (/blog/post), una stringa di query (?id=42), e un frammento (#section). la Parser URL Divide qualsiasi collegamento in quelle parti utilizzando il motore URL WhatWG del browser, decodifica la query in una tabella di valori chiave ordinata (chiavi ripetute mantenute separate), mostra la porta effettiva per lo schema e presupponehttps://Se incolli un dominio nudo. Funziona interamente nel tuo browser, quindi i collegamenti con i token rimangono privati.
Quali sono le parti di un URL?
Ogni URL segue la stessa grammatica, definita dallo Standard WHATWG URL - le specifiche effettivamente implementate dai browser Una volta che puoi nominare le parti, la maggior parte dei bug degli URL diventano ovvi Ecco l'anatomia completa, utilizzando un esempio volutamente occupato:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
Abbatterlo:
| componente | Valore di esempio | Che cos'è |
|---|---|---|
| sistema | https |
il protocollo. Decide la porta predefinita e come viene effettuata la richiesta. |
| nome utente | john |
credenziali facoltative, prima del @. |
| password | s3cret |
credenziali facoltative, dopo : nelle informazioni utente. |
| nome host | shop.example.co.uk |
il dominio o l'indirizzo IP, senza porta. |
| porto | 8443 |
facoltativo. Ritorna al valore predefinito dello schema quando omesso. |
| ospite | shop.example.co.uk:8443 |
Nome host più porta, quando è presente una porta. |
| origine | https://shop.example.co.uk:8443 |
Scheme più host - l'unità che i browser utilizzano per la sicurezza. |
| via | /catalog/shoes |
la posizione della risorsa sull'host. |
| interrogare | ?color=red&size=42 |
parametri chiave-valore dopo ?. |
| frammento | #reviews |
Ancora lato cliente dopo il #, mai inviato al server. |
Il parser espone ognuno di questi come propria riga con un pulsante di copia, quindi non dovrai mai più estrarre un nome host da un URL di mostro. Segnala anche un paio di cose nascoste che la stringa RAW nasconde: se la porta mostrata è esplicita o l'impostazione predefinita dello schema e se l'host è un dominio denominato o un IP RAW.
Qual è la differenza tra nome host, host e origine?
Questi tre inciampano costantemente le persone e la confusione causa veri bug: guasti CORS, errori di scoping dei cookie, disallineamenti dei reindirizzamenti. Non sono sinonimi. IL Whatwg URL standard la definizione che i browser effettivamente implementano è il luogo in cui risolvere una discussione su ciò che conta come origine.
nome host è solo il dominio o l'IP: shop.example.co.uk. Nessun porto, nessun schema. È quello che metteresti in una ricerca DNS.
ospite è il nome host più la porta, ma solo quando una porta è presente nell'URL. per shop.example.co.uk:8443 L'host è shop.example.co.uk:8443. Per una pianura https://shop.example.co.uk/ L'host e il nome host sono identici, perché la porta predefinita 443 è implicita anziché scritta. Quella regola "solo quando presente" è sottile ed è per questo che lo stesso sito può sembrare avere due host diversi.
origine IS Schema Plus Host: https://shop.example.co.uk:8443. Questo è quello che interessa di più ai browser, perché la politica della stessa origine - il fondamento della sicurezza web - confronta le origini, non i nomi host Due URL condividono un'origine solo se il loro schema, nome host, e Porta tutto corrispondono. http://example.com e https://example.com sono origini diverse perché lo schema differisce. https://example.com e https://example.com:8443 sono origini diverse perché la porta è diversa, anche se il nome host è lo stesso. Se un recupero non riesce con un errore CORS, confrontare le due origini fianco a fianco nel parser è solitamente il modo più veloce per individuare la mancata corrispondenza.
Come si analizza una stringa di query?
La stringa di query è il luogo in cui vive la maggior parte del dolore quotidiano, perché è un blob piatto e dall'aspetto non evaso che è effettivamente strutturato e codificato in percentuale. Il parser lo divide per te: tutto dopo il ?, rotto &, con ciascuno key=value coppia decodificato ed elencato in una tabella nel suo ordine originale.
Qui contano due comportamenti. prima, deciframento. un parametro scritto come q=trail%20runner Sul filo è mostrato come trail runner Nella colonna Valore, perché %20 è uno spazio codificato in percentuale. il crudo search stringa è ancora mostrato intatto nella lista dei componenti, in modo da poter confrontare i moduli codificati e decodificati - inestimabile quando si sospetta doppia codifica, come il mio %2520 bug OAuth.
secondo, Tasti ripetuti. Un URL può legittimamente portare la stessa chiave più di una volta: ?tag=react&tag=typescript&tag=node. Molti parser ingenui li comprimono, mantenendo solo il primo o l'ultimo valore e perdendo silenziosamente i dati. Questo è sbagliato: le chiavi ripetute sono il modo in cui i moduli HTML inviano campi multi-selezionati e il modo in cui molte API esprimono gli array. Il parser mantiene ogni occorrenza come propria riga, in ordine, in modo da vedere tutti e tre i tag. Quando copi la query come JSON, le chiavi ripetute diventano un array, che è la forma che il codice più si aspetta.
Non hai nemmeno bisogno di un URL completo per usarlo Incolla solo una stringa di query - color=red&size=42 - e lo strumento lo analizza da solo È il modo più veloce che conosco per dare un senso a un payload webhook o a un link di tracciamento che qualcuno ti ha inoltrato.
Come si usa il parser URL?
Lo strumento è progettato per togliersi di mezzo Incolla un URL nel singolo input e analizza dal vivo mentre digiti: nessun pulsante da premere Un collegamento di esempio è precaricato in modo da poter vedere immediatamente la suddivisione completa e un pulsante Cancella svuota il campo.
Non devi digitare lo schema. Incolla un ospite nudo come example.com/pricing E il parser si antepone https:// automaticamente, poi ti dice che lo ha fatto con una piccola nota, quindi non sei mai confuso su da dove proviene lo schema Incolla uno schema esplicito - http://, ftp://, ssh:// - e invece lo rispetta.
L'uscita ha quattro zone. In alto, il URL normalizzato - la forma canonica del browser's motore prodotto, con un pulsante di copia, che è utile per cogliere sottili differenze di normalizzazione. Al di sotto di questo, il componenti Tabella, una riga etichettata per parte, ciascuna copiabile in modo indipendente. poi Segmenti di percorso, suddiviso in chip indicizzati in modo da un percorso profondo come /api/v2/users/42/orders è leggibile a colpo d'occhio. Finalmente il Parametri di query Tabella, decodificato e ordinato, con un'azione "copia come JSON" che trasforma l'intera query in un oggetto pulito.
Tutto funziona nel tuo browser utilizzando il suo motore di URL nativo. Questa è una scelta deliberata: gli URL contengono regolarmente token di accesso, ID sessione, parametri firmati e nomi host interni e nessuno di questi dovrebbe essere spedito a un server solo per essere letto. Niente che incollate lascia il dispositivo e lo strumento continua a funzionare offline. È lo stesso approccio alla privacy dietro l'intero toolkit, in cui entro nel Guida al kit per gli sviluppatori web.
Quando raggiungo un parser URL?
Alcune situazioni si presentano ancora e ancora nel mio lavoro. reindirizzamenti e richiamate di debug è quello più grande: flussi OAuth, URL di restituzione dei pagamenti, strette di mano SSO, che falliscono tutti su piccoli disallineamenti che diventano visibili solo quando decomponi entrambi gli URL. Collegamenti di monitoraggio dell'audit è un altro: gli URL di marketing sono spesso una pagina di base più una dozzina di parametri UTM e piattaforma AD e leggerli come un battito da tavolo che strizza gli occhi su una stringa di 300 caratteri. Se stai costruendo quei link invece di leggerli, il Costruttore di UTM è l'altra metà dello stesso flusso di lavoro.
Poi c'è API lavoro - ispezionando i parametri di query effettivamente inviati da un client, o decodificando il modo in cui un endpoint si aspetta i suoi filtri. e Revisione della sicurezza: Un collegamento sconosciuto in un'e-mail o in un registro è molto più sicuro da capire analizzandone le parti (quale host lo fa davvero punto? Quel nome host è un IP?) che facendo clic su di esso. Il parser espone il vero nome host e flags host letterali IP, che è esattamente le informazioni che desideri prima di fidarti di un collegamento. Ho scritto di più sull'assemblaggio di questo tipo di kit di ispezione nel Guida agli strumenti di debug dell'API.
In che modo l'analisi si collega alla codifica e a slugs?
Un parser URL è un angolo di una piccola famiglia di strumenti di collegamento e sapere quale ti serve fa risparmiare tempo. analisi sano un URL esistente e lo separa. codifica fa la direzione opposta a livello di carattere - trasformando spazi e caratteri speciali nelle loro forme codificate in percentuale in modo che sopravvivano all'interno di un URL, e viceversa Quando è necessario incorporare in modo sicuro un valore in una stringa di query, o decodificarne uno che è mutilato, cioè il Encoder/decoder URL, e si accoppia naturalmente con il parser: analizzare per vedere la struttura, codificare per correggere un valore rotto.
__GENERAZIONE Slug è un terzo lavoro correlato: prendere un titolo umano come & quot;10 suggerimenti per build e quot più veloci; e trasformarlo in un pulito 10-tips-for-faster-builds Segmento di percorso. questo è ciò che il Slug Generatore maniglie, ed è ciò che produce la ordine path componente il parser in seguito si legge indietro Pensalo come una pipeline: slugify per costruire buoni percorsi, codificare per rendere i valori sicuri per l'URL, analizzare per ispezionare il collegamento finito Ogni strumento fa una parte del ciclo di vita dell'URL e lo fa nel browser.
E gli indirizzi IP e i domini internazionalizzati?
Non tutti gli host sono in ordine example.com. Alcuni URL puntano agli indirizzi IP grezzi e il parser riconosce entrambe le forme. un IPv4 letterale http://192.168.1.10:3000/ ha un nome host di 192.168.1.10, e lo strumento lo segnala come un IP piuttosto che un dominio - utile quando si sta verificando un collegamento e si desidera sapere istantaneamente se si rivolge a un sito con nome o un indirizzo nudo, che è un segnale comune nei collegamenti sospetti I letterali IPv6 sono avvolti tra parentesi quadre in un URL, come in http://[2001:db8::1]:8080/, e le parentesi fanno parte della sintassi ospite, non della decorazione; il parser gestisce correttamente quella forma tra parentesi invece di soffocare sui due punti, che altrimenti sembrerebbero separatori di porte.
I nomi di dominio internazionalizzati sono l'altro caso marginale Un host scritto in caratteri non ASCII - ad esempio un dominio con lettere accentate o non latine - viene convertito dal browser's URL engine nel suo Punycode xn-- modulo per la richiesta effettiva, perché DNS parla solo ASCII. Vedere il normalizzato href Nel parser ti mostra esattamente cosa risolverà il browser, il che a volte sorprende le persone che si aspettavano che il loro bel dominio Unicode viaggiasse invariato. Per il dominio di primo livello, il parser estrae l'etichetta finale di un host denominato, quindi shop.example.co.uk segnala un TLD di uk. Questa è una regola deliberatamente semplice: non cerca di decomprimere suffissi in più parti come .co.uk in un dominio registrabile, perché farlo correttamente richiede l'elenco dei suffissi pubblici, che è un set di dati in movimento di grandi dimensioni. Per un'ispezione rapida l'ultima etichetta è il segnale utile e per qualsiasi cosa più rigorosa si raggiunge una libreria dedicata.
Un esempio lavorato lo lega insieme. Supponiamo che un fornitore di pagamenti continui a rifiutare l'URL di reso. ti sei registrato https://app.example.com/checkout/return Ma la richiesta fallita mostra https://app.example.com:443/checkout/return/. Analizza entrambi. Il parser mostra il primo ha host app.example.com (porta predefinita, nessuna barra finale sul percorso) e il secondo ha host app.example.com anche - ma il suo percorso è /checkout/return/ con una barra finale, e la sua porta è stata scritta esplicitamente come :443. Due differenze su cui l'occhio scivola, entrambi fatali a un controllo esatto. Una volta che puoi vederli come componenti etichettati separati, la correzione è ovvia: normalizza il taglio finale e rilascia la porta esplicita ridondante.
Errori comuni durante la lettura degli URL
Vale la pena nominare gli errori ricorrenti. confondere il frammento con il percorso o la query - tutto dopo # è il frammento, viene gestito interamente dal browser e non viene mai inviato al server, quindi un parametro che metti dopo # non raggiungerà il tuo backend. Supponendo che una porta mancante non significhi nessuna porta - per porta omessa si intende lo schema morigere (443 per https, 80 per http), che il parser rende esplicito in modo da sapere quale porta si verificherà davvero.
ignorando la doppia codifica - se un valore assomiglia a %2520 invece di %20, è stato codificato due volte; analizzalo e se il valore decodificato contiene ancora una sequenza percentuale, decodifica di nuovo. Fidarsi del testo visibile di un collegamento - il testo che vedi e quello reale href può differire completamente, che è l'intero meccanismo alla base del phishing; l'analisi rivela il vero host di destinazione. e Trattare le chiavi di query ripetute come duplicati da scartare - sono spesso array significativi e la loro eliminazione perde dati.
Domande frequenti
Quali sono le parti di un URL?
Un URL ha uno schema (https), credenziali facoltative (utente:pass@), un host (esempio.com) con una porta opzionale, un percorso (/blog/post), una stringa di query opzionale (?id=42) e un frammento facoltativo (#sezione). Questo parser separa ed etichetta ciascuno.
Come si analizza una stringa di query?
Incolla l'URL completo e leggi la tabella delle query o incolla solo la stringa di query da sola. Il parser lo divide su e commerciale, decodifica la codifica percentuale ed elenca ogni coppia chiave-valore in ordine. Tasti ripetuti come TAG=A&tag=B vengono mantenute come righe separate.
Qual è la differenza tra nome host, host e origine?
Il nome host è solo il dominio o l'IP (example.com). L'host aggiunge la porta quando è presente (example.com:8443). Origin è lo schema più host (https://example.com:8443) ed è ciò che i browser utilizzano per lo stesso controllo di sicurezza di origine.
Quale porta viene utilizzata quando un URL non ha un numero di porta?
lo schema decide. L'impostazione predefinita di HTTPS è 443, HTTP a 80, SSH a 22 e FTP a 21. Questo parser mostra la porta effettiva e la contrassegna come predefinita, quindi sai quale porta utilizzerebbe effettivamente una richiesta.
Il parser decodifica i caratteri codificati in percentuale?
Sì, per i valori di query. Un parametro come name=John%20DoE viene mostrato nella tabella come "John Doe. La stringa di ricerca grezza viene mostrata anche inalterata in modo da poter confrontare i moduli codificati e decodificati.
Posso analizzare un URL senza digitare la parte https?
si. Se incolli un host o un percorso nudo come example.com/pricing, il parser prescrive automaticamente https:// e nota che ha assunto lo schema. Incolla esplicitamente uno schema, ad esempio http:// o ftp://, per sovrascrivere tale ipotesi.
Perché il mio URL non riesce ad analizzare?
Di solito l'host è mancante o non è corretto, lo schema è scritto in modo errato o la stringa contiene caratteri illegali in un URL e non sono codificati in percentuale. Controllare gli spazi, le parentesi non evacuate o una barra mancante dopo lo schema.
È sicuro incollare gli URL con token o ID sessione?
si. L'analisi viene eseguita interamente nel tuo browser utilizzando il suo motore di URL nativo. Il collegamento non viene mai inviato a un server, mai registrato e mai archiviato, quindi gli URL contenenti token di accesso, chiavi API o nomi host interni rimangono sul tuo dispositivo.
