Perdi uma tarde uma vez para uma url que parecia bom. Um retorno de chamada OAuth continuou falhando, o redirecionamento de URI "correspondeu" ao provedor, e não consegui ver por que o aperto de mão quebrou. A resposta, quando finalmente colei a coisa em um analisador, foi uma barra final no caminho em um lugar e nenhuma no outro, além de um state Parâmetro que foi duplamente codificado, então %20 tinha se tornado %2520. Para o olho humano, as duas URLs eram idênticas. Para o servidor OAuth, eles eram strings diferentes e era correto rejeitar a incompatibilidade.
Esse é o problema com URLs: eles são densos, são fáceis de interpretar mal, e os detalhes que quebram as coisas - uma barra codificada, uma porta perdida, uma chave de consulta repetida, um fragmento onde você esperava um caminho - são exatamente os que se escondem em uma parede de caracteres. Eu construo [Toolz.dev](/, e passo tempo suficiente olhando para strings de consulta enquanto depuro que construí um analisador de url para fazer o olhar para mim. Cole um link, coloque todos os componentes rotulados e todos os parâmetros de consulta decodificados em uma tabela. Este guia explica o que são esses componentes, por que as distinções são importantes e como usá-los.
tl;dr: Um URL é feito de um esquema (
https), credenciais opcionais (user:pass@), um host (example.com) Com uma porta opcional, um caminho (/blog/post), uma string de consulta (?id=42), e um fragmento (#section). o analisador de url Divide qualquer link para essas partes usando o mecanismo de URL WhatWG do próprio navegador, decodifica a consulta em uma tabela de valores de chave ordenadas (chaves repetidas separadas), mostra a porta efetiva do esquema e assumehttps://Se você colar um domínio nu. Ele é executado inteiramente no seu navegador, então os links com tokens permanecem privados.
Quais são as partes de um URL?
Cada URL segue a mesma gramática, definida pelo WHATWG URL Standard - os navegadores de especificação realmente implementam Uma vez que você pode nomear as partes, a maioria dos bugs de URL se torna óbvia Aqui está a anatomia completa, usando um exemplo deliberadamente ocupado:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
quebrando isso:
| componente | Valor de exemplo | O que é |
|---|---|---|
| esquema | https |
O protocolo. Decide a porta padrão e como a solicitação é feita. |
| nome de usuário | john |
credencial opcional, antes do @. |
| senha | s3cret |
credencial opcional, após o : no UserInfo. |
| Nome do host | shop.example.co.uk |
O domínio ou endereço IP, sem porta. |
| porto | 8443 |
opcional. Retorna ao padrão do esquema quando omitido. |
| hospedeiro | shop.example.co.uk:8443 |
Nome do host mais a porta, quando uma porta está presente. |
| origem | https://shop.example.co.uk:8443 |
Scheme plus host - os navegadores de unidade usam para segurança. |
| caminho | /catalog/shoes |
O local do recurso no host. |
| indagar | ?color=red&size=42 |
parâmetros de valor-chave após o ?. |
| fragmento | #reviews |
âncora do lado do cliente após o #, nunca enviado ao servidor. |
O analisador apresenta cada um deles como sua própria linha com um botão de cópia, para que você nunca mais precise extrair um nome de host de um URL de monstro. Ele também sinaliza algumas coisas que a string bruta oculta: se a porta mostrada é explícita ou o padrão do esquema e se o host é um domínio nomeado ou um IP bruto.
Qual é a diferença entre hostname, host e origem?
Esses três tropeçam as pessoas constantemente, e a confusão causa bugs reais - falhas CORS, erros de escopo de cookies, incompatibilidades de redirecionamento Eles não são sinônimos O whatwg standard de url a definição dos navegadores é realmente implementada e é o lugar para resolver uma discussão sobre o que conta como origem.
Nome do host É apenas o domínio ou o IP: shop.example.co.uk. Sem porto, sem esquema. É o que você colocaria em uma pesquisa de DNS.
hospedeiro é o nome do host mais a porta, Mas somente quando uma porta está presente no URL. para shop.example.co.uk:8443 O anfitrião é shop.example.co.uk:8443. para uma planície https://shop.example.co.uk/ O host e o nome do host são idênticos, porque a porta padrão 443 está implícita em vez de escrita. Essa regra "somente quando presente" é sutil e é por isso que o mesmo site pode parecer ter dois hosts diferentes.
origem É o esquema mais host: https://shop.example.co.uk:8443. Este é o único navegador que mais se preocupa, porque a política de mesma origem - a base da segurança da web - compara origens, não nomes de host. Dois URLs compartilham uma origem somente se seu esquema, nome de host, e Porta todos combinam. http://example.com e https://example.com são origens diferentes porque o esquema difere. https://example.com e https://example.com:8443 são origens diferentes porque a porta difere, mesmo que o nome do host seja o mesmo. Se uma busca estiver falhando com um erro CORS, comparar as duas origens lado a lado no analisador geralmente é a maneira mais rápida de identificar a incompatibilidade.
Como faço para analisar uma string de consulta?
A string de consulta é onde a maior parte da dor do dia-a-dia vive, porque é uma bolha plana e sem escapamento, que é realmente estruturada e codificada por porcentagem. O analisador divide para você: tudo após o ?, quebrado &, com cada key=value Par descodificado e listado em uma tabela em sua ordem original.
Dois comportamentos importam aqui. Primeiro, decifração. Um parâmetro escrito como q=trail%20runner no fio é mostrado como trail runner Na coluna Valor, porque %20 é um espaço codificado por cento. o cru search string ainda é mostrado intocado na lista de componentes, então você pode comparar os formulários codificados e decodificados - inestimável quando você suspeita de codificação dupla, como o meu %2520 bug oauth.
segundo, teclas repetidas. Um URL pode legitimamente carregar a mesma chave mais de uma vez: ?tag=react&tag=typescript&tag=node. Muitos analisadores ingênuos colapsam estes, mantendo apenas o primeiro ou último valor e silenciosamente perdendo dados Isso está errado - chaves repetidas são como formulários HTML enviam campos multi-selecionados e como muitas APIs expressam arrays O analisador mantém cada ocorrência como sua própria linha, em ordem, para que você veja todas as três tags Quando você copia a consulta como JSON, chaves repetidas se tornam uma matriz, que é a forma que a maioria dos códigos espera.
Você nem precisa de um URL completo para usar isso Cole apenas uma string de consulta - color=red&size=42 - e a ferramenta analisa-o por conta própria É a maneira mais rápida que conheço de dar sentido a uma carga útil de webhook ou a um link de rastreamento que alguém encaminhou para você.
Como eu uso o analisador de URL?
A ferramenta foi projetada para sair do seu caminho Cole um URL na única entrada e ele analisa ao vivo enquanto você digita - nenhum botão para pressionar Um link de amostra é pré-carregado para que você possa ver o detalhamento completo imediatamente, e um botão Limpar esvazia o campo.
Você não precisa digitar o esquema. Cole um host nu como example.com/pricing e o analisador antecede https:// automaticamente, então diz que fez isso com uma pequena nota, para que você nunca fique confuso sobre de onde veio o esquema Cole um esquema explícito - http://, ftp://, ssh:// - e em vez disso respeita isso.
A saída tem quatro zonas. No topo, o URL normalizado - a forma canônica do navegador & #39;s motor produzido, com um botão de cópia, que é útil para detectar diferenças sutis de normalização. Abaixo disso, o componentes tabela, uma linha rotulada por parte, cada uma delas copiável independentemente. então Segmentos de caminho, dividido em chips indexados para um caminho profundo como /api/v2/users/42/orders é legível de relance. Finalmente o Parâmetros de consulta Tabela, decodificada e ordenada, com uma ação "copiar como JSON" que transforma toda a consulta em um objeto limpo.
Tudo é executado no seu navegador usando seu mecanismo de URL nativo. Essa é uma escolha deliberada: os URLs contêm rotineiramente tokens de acesso, IDs de sessão, parâmetros assinados e nomes de host internos, e nada disso deve ser enviado para um servidor apenas para ser lido. Nada que você cola deixa seu dispositivo e a ferramenta continua funcionando offline. É a mesma abordagem de privacidade por trás de todo o kit de ferramentas, que entro no Guia do kit de ferramentas para desenvolvedores web.
Quando devo procurar um analisador de URL?
Algumas situações surgem de novo e de novo no meu próprio trabalho. Redirecionamentos e retornos de chamada de depuração é o grande - fluxos OAuth, URLs de retorno de pagamento, handshakes SSO, todos os quais falham em pequenas incompatibilidades que só se tornam visíveis quando você decompõe ambos os URLs. Auditoria de links de rastreamento É outra: os URLs de marketing geralmente são uma página básica, além de uma dúzia de parâmetros de plataforma de anúncios e UTM, e lê-los como uma mesa supera os olhos apertados em uma string de 300 caracteres. Se você está construindo esses links em vez de lê-los, o Construtor UTM é a outra metade do mesmo fluxo de trabalho.
então há Trabalho de API - inspecionar os parâmetros de consulta que um cliente realmente enviou ou fazer engenharia reversa de como um endpoint espera seus filtros. E Revisão de segurança: um link desconhecido em um e-mail ou um log é muito mais seguro de entender, analisando suas partes (qual host faz isso de fato Aponte para? Esse nome de host é um IP?) do que clicando nele. O analisador expõe os hosts verdadeiros do nome do host e sinalizadores de IP, que são exatamente as informações que você deseja antes de confiar em um link. Eu escrevi mais sobre como montar esse tipo de kit de inspeção no Guia de ferramentas de depuração de API.
Como a análise se relaciona com a codificação e slugs?
Um analisador de URL é um canto de uma pequena família de ferramentas de link e saber qual você precisa economizar tempo. análise lê Um URL existente e o separa. codificação faz a direção oposta no nível do caractere - transformando espaços e caracteres especiais em seus formulários codificados por porcentagem para que eles sobrevivam dentro de uma URL e voltem. Quando você precisa incorporar um valor com segurança em uma string de consulta ou decodificar uma que esteja mutilada, esse é o Codificador/decodificador de URL, e combina naturalmente com o analisador: Analisar para ver a estrutura, codificar para corrigir um valor quebrado.
Slug geração é um terceiro trabalho relacionado - obter um título humano como & quot;10 dicas para construções e quot mais rápidas; e transformando-o em um limpo 10-tips-for-faster-builds Segmento de caminho. é isso que o Slug Gerador alças, e é o que produz a arrumação path componente o analisador mais tarde lê de volta Pense nisso como um pipeline: slugify para construir bons caminhos, codificar para tornar os valores seguros para URL, analisar para inspecionar o link acabado Cada ferramenta faz uma parte do ciclo de vida da URL e faz isso no navegador.
E os endereços IP e domínios internacionalizados?
Nem todo hospedeiro é arrumado example.com. Alguns URLs apontam para endereços IP brutos e o analisador reconhece os dois formulários. um literal ipv4 como http://192.168.1.10:3000/ Possui um nome de host de 192.168.1.10, e a ferramenta sinaliza-o como um IP em vez de um domínio - útil quando você está auditando um link e quer saber instantaneamente se ele tem como alvo um site nomeado ou um endereço simples, que é um sinal comum em links suspeitos Os literais IPv6 são embrulhados entre colchetes em uma URL, como em http://[2001:db8::1]:8080/, e os colchetes fazem parte da sintaxe do host, não da decoração; o analisador manipula corretamente em vez de se engasgar nos dois pontos, que de outra forma pareceriam separadores de porta.
Nomes de domínio internacionalizados são o outro caso de borda Um host escrito em caracteres não ASCII - digamos, um domínio com letras acentuadas ou não latinas - é convertido pelo navegador & #39; s mecanismo de URL em seu Punycode xn-- Formulário para a solicitação real, porque o DNS fala apenas ASCII. vendo o normalizado href No analisador, mostra exatamente o que o navegador resolverá, o que ocasionalmente surpreende as pessoas que esperavam que seu belo domínio Unicode viajasse inalterado. Para o domínio de nível superior, o analisador extrai o rótulo final de um host nomeado, portanto shop.example.co.uk Relata um TLD de uk. Essa é uma regra deliberadamente simples - ela não tenta descompactar sufixos de várias partes como .co.uk em um domínio registrável, porque fazer isso requer a lista de sufixos públicos, que é um grande conjunto de dados em movimento. Para uma inspeção rápida, a última etiqueta é o sinal útil e, para qualquer coisa mais rigorosa, você procura uma biblioteca dedicada.
Um exemplo trabalhado une-o. Digamos que um provedor de pagamento continue rejeitando seu url de devolução. você registrou https://app.example.com/checkout/return Mas a solicitação de falha mostra https://app.example.com:443/checkout/return/. Analise ambos. O analisador mostra que o primeiro tem host app.example.com (porta padrão, nenhuma barra final no caminho) e o segundo tem o host app.example.com também - mas seu caminho é /checkout/return/ com uma barra final, e sua porta foi escrita explicitamente como :443. Duas diferenças sobre o qual o olho desliza, ambas fatais para uma verificação de correspondência exata. Depois de poder vê-los como componentes rotulados separados, a correção é óbvia: normalize a barra final e solte a porta explícita redundante.
Erros comuns ao ler URLs
Vale a pena citar os erros recorrentes. confundindo o fragmento com o caminho ou consulta - tudo depois # é o fragmento, ele é totalmente manuseado pelo navegador e nunca é enviado ao servidor, portanto, um parâmetro que você coloca depois # não chegará ao seu back-end. Assumir uma porta ausente significa que nenhuma porta - uma porta omitida significa o esquema falta (443 para HTTPS, 80 para HTTP), que o analisador torna explícito para que você saiba qual porta realmente será afetada.
Ignorando a codificação dupla - se um valor se parecer %2520 em vez de %20, foi codificado duas vezes; analisá-lo e, se o valor decodificado ainda contiver uma seqüência de porcentagem, decodifique novamente. Confiando no texto visível de um link - o texto que você vê e o real href Pode variar completamente, o que é todo o mecanismo por trás do phishing; a análise revela o host de destino real. e Tratando as teclas de consulta repetidas como duplicatas para descartar - muitas vezes são matrizes significativas e eliminá-las perde dados.
Perguntas frequentes
Quais são as partes de um URL?
Um URL tem um esquema (https), credenciais opcionais (usuário:pass@), um host (exemplo.com) com uma porta opcional, um caminho (/blog/post), uma string de consulta opcional (?id=42) e um fragmento opcional (#section). Este analisador separa e rotula cada um.
Como faço para analisar uma string de consulta?
Cole o URL completo e leia a tabela de consultas ou cole apenas a string de consulta. O analisador o divide em e comercial, decodifica a codificação por cento e lista todos os pares de chave-valor em ordem. Teclas repetidas, como tag=a&tag=b, são mantidas como linhas separadas.
Qual é a diferença entre hostname, host e origem?
Hostname é apenas o domínio ou IP (example.com). O host adiciona a porta quando uma está presente (example.com:8443). Origem é o esquema mais host (Hospededor de Ehttps://example.com:8443) e é o que os navegadores usam para a mesma origem de verificação de segurança.
Qual porta é usada quando um URL não tem um número de porta?
O esquema decide. O padrão HTTPS é 443, HTTP para 80, SSH para 22 e FTP para 21. Este analisador mostra a porta efetiva e a marca como padrão, então você sabe qual porta realmente usaria.
O analisador decodifica caracteres codificados por porcentagem?
Sim, para valores de consulta. Um parâmetro como NAME=John%20DOE é mostrado decodificado como "John Doe" na tabela. A string de pesquisa bruta também é mostrada intocada para que você possa comparar os formulários codificados e decodificados.
Posso analisar um URL sem digitar a parte HTTPS?
Sim. Se você cola um host ou caminho nu como example.com/pricing, o analisador atrela automaticamente https:// e observa que ele assumiu o esquema. Cole um esquema explicitamente, como http:// ou ftp://, para substituir essa suposição.
Por que meu url não analisa?
Normalmente, o host está ausente ou malformado, o esquema é escrito incorretamente ou a string contém caracteres que são ilegais em uma URL e não são codificados por porcentagem. Verifique se há espaços, suportes sem escapamento ou uma barra perdida após o esquema.
É seguro colar URLs com tokens ou IDs de sessão?
Sim. A análise é executada inteiramente no seu navegador usando o mecanismo de URL nativo. O link nunca é enviado a um servidor, nunca registrado e nunca armazenado, portanto, URLs contendo tokens de acesso, chaves de API ou nomes de host internos permanecem no seu dispositivo.
