Os dois pontos `:` são seguros para uso de URL amigável?


109

Estamos projetando um sistema de URL que especificará as seções do aplicativo como palavras separadas por barras. Especificamente, isso está no GWT, portanto, as partes relevantes do URL estarão no hash (que será interpretado por uma camada de controlador no lado do cliente):

http://site/gwturl#section1/section2

Algumas seções podem precisar de atributos adicionais, que gostaríamos de especificar com um :, para que as partes da seção do URL não sejam ambíguas. O código seria dividido primeiro /, depois :, assim:

http://site/gwturl#user:45/comments

Claro, estamos fazendo isso para facilitar o uso de url, portanto, gostaríamos de ter certeza de que nenhum desses caracteres que terão um significado especial será codificado por url por navegadores ou qualquer outro sistema e termine com um url como isto:

http://site/gwturl#user%3A45/comments <--- BAD

O uso de dois pontos dessa maneira é seguro (ou seja, não será codificado automaticamente) para navegadores, sistemas de favoritos e até mesmo Javascript ou código Java?


Talvez seja uma boa ideia especificar (mais claramente) que você usa os URLs apenas no lado do cliente? Uma vez que muitas das respostas (como a minha) parecem assumir que você enviará a URL para um servidor usando HTTP.
Veger

Editado para esclarecer que o uso do fragmento está acontecendo no lado do cliente.
Nicole

Estou curioso: depois de 10 meses, esse esquema de url funcionou para você? Estou pensando em usar o mesmo esquema.
Jonathan Swinney

1
@Jonathan Swinney, Infelizmente, mudei deste projeto (e da empresa), embora as respostas aqui tenham me convencido de que é o caminho a percorrer. Se eu fosse começar um novo projeto, usaria este esquema, mas também usaria #!para indicar que as páginas têm estado - consulte googlewebmastercentral.blogspot.com/2009/10/… (Esta proposta foi cumprida por usuários AJAX intensos, como o Facebook)
Nicole

Acabei de descobrir que o WhatsApp corta uma URL nos primeiros dois pontos, por isso, por exemplo, torna uma URL do Google Maps inútil. Então, sim, é importante escapar disso.
Petruza de

Respostas:


84

Recentemente, escrevi um codificador de URL, então isso está bem fresco em minha mente.

http://site/gwturl#user:45/comments

Todos os caracteres na parte do fragmento ( user:45/comments) são perfeitamente válidos para URIs RFC 3986 .

As partes relevantes do ABNF :

fragment      = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Além dessas restrições, a parte do fragmento não tem estrutura definida além daquela que seu aplicativo fornece. O esquema, http, diz apenas que você não envia esta parte para o servidor.


EDITAR:

D'oh!

Apesar de minhas afirmações sobre a especificação URI, irreputable fornece a resposta correta quando ele aponta que a especificação HTML 4 restringe nomes / identificadores de elemento .

Observe que as regras do identificador estão mudando no HTML 5 . As restrições de URI ainda serão aplicáveis ​​(no momento da escrita, havia alguns problemas não resolvidos em torno do uso de URIs do HTML 5).


Acho que você está no caminho certo, pode explicar isso um pouco mais? Não enviar isso para o servidor não é um problema, pois estamos usando GWT. Só não tenho certeza se entendi bem a sintaxe especificada pela seção que você citou.
Nicole

Mas :é um gen-delim, não um sub-delim.
bobince

1
O ponto e vírgula é válido para um pchar, portanto, se ele está em sub-delim ou gen-delim não é um problema
Veger

@bobince - :está dentro pchar, que está dentro fragment, então :é permitido. @Renesis - A Wikipedia tem um artigo sobre ABNF en.wikipedia.org/wiki/ABNF Você está basicamente olhando para uma lista de caracteres permitidos, onde /significa OU . Não fiz nenhuma programação GWT, então não sei como ele usa a parte do fragmento de URIs.
McDowell

Uma última pergunta - você tem alguma ideia sobre a aplicação real desta especificação? Isso significa que os navegadores devem / irão ignorar (pular a codificação de) o :no fragmento?
Nicole

59

Além da análise de McDowell sobre o padrão URI, lembre-se também de que o fragmento deve ser um nome de âncora HTML válido. De acordo com http://www.w3.org/TR/html4/types.html#type-name

Os tokens de ID e NOME devem começar com uma letra ([A-Za-z]) e podem ser seguidos por qualquer número de letras, dígitos ([0-9]), hifens ("-"), sublinhados ("_") , dois pontos (":") e pontos (".").

Então você está com sorte. ":" é explicitamente permitido. E ninguém deve "%" - escapar disso, não apenas porque "%" é um char ilegal lá, mas também porque o fragmento deve corresponder ao nome da âncora char-por-char, portanto, nenhum agente deve tentar adulterá-los de qualquer forma.

No entanto, você tem que testá-lo. Os padrões da Web não são seguidos estritamente; às vezes, os padrões são conflitantes. Por exemplo, HTTP / 1.1 RFC 2616 não permite string de consulta na URL de solicitação, enquanto HTML constrói uma ao enviar um formulário com o método GET. O que for implementado no mundo real ganha no final do dia.


58

MediaWiki e outros motores wiki usam dois pontos em seus URLs para designar namespaces, aparentemente sem maiores problemas.

por exemplo, http://en.wikipedia.org/wiki/Template:Welcome


31
Resposta mais relevante. Todos nós sabemos que o que está nas especificações tem pouco a ver com a realidade no desenvolvimento web. Você não terá uma garantia de "segurança" muito melhor do que "um dos 10 melhores sites do mundo faz isso".
Steven Collins

1
@StevenCollins Não é mais relevante do que a resposta dada 3 anos antes desta que afirma exatamente a mesma coisa :)
Martin James

7

Eu não contaria com isso. Provavelmente, o URL será codificado %3Apor muitos user agents.


1
@arbales: Sim. Alguns agentes de usuário menos compatíveis deixarão URLs não compatíveis sem adornos.
Asaph

4

De URLEncoderjavadoc:

Para obter mais informações sobre codificação de formulário HTML, consulte a especificação HTML .

Ao codificar uma String, as seguintes regras se aplicam:

  • Os caracteres alfanuméricos "a" a "z", "A" a "Z" e "0" a "9" permanecem os mesmos.
  • Os caracteres especiais ".", "-", "*" e "_" permanecem os mesmos.
  • O caractere de espaço "" é convertido em um sinal de mais "+".
  • Todos os outros caracteres não são seguros e são primeiro convertidos em um ou mais bytes usando algum esquema de codificação. Então, cada byte é representado pela string de 3 caracteres "% xy", onde xy é a representação hexadecimal de dois dígitos do byte. O esquema de codificação recomendado a ser usado é UTF-8. No entanto, por motivos de compatibilidade, se uma codificação não for especificada, a codificação padrão da plataforma será usada.

Ou seja, :não é seguro.


3

Não vejo o Firefox ou o IE8 codificando alguns dos URLs da Wikipedia que incluem o caractere.


1
O Opera também mantém o ponto e vírgula, mas contar com esse comportamento não é uma boa coisa a fazer
Veger

1
Renesis está falando sobre o fragmento da URL e não sobre o caminho da URL.
Gumbo

A Wikipedia foi um dos meus pensamentos ao escrever esta pergunta. O uso de dois pontos é tecnicamente inválido / inseguro então? Costumo ver (e) em URLs codificados da Wikipedia, mas nunca os dois pontos, o que me deixou um pouco confuso.
Nicole

3
The Wayback Machine tem um: em muitos de seus links - por exemplo, web.archive.org/web/20080822150704/http://stackoverflow.com
barrowc

2

Os dois pontos são usados ​​como divisão entre o nome de usuário e a senha se um protocolo exigir autenticação.


0

O cólon não é seguro. Veja aqui


Essa página não explica por que eles não são seguros. O RFC2396 referenciado também não diz que deve ser escapado. Além disso, o script conversor fornecido não o codifica (pelo menos no Chrome 9).
Adam Lindberg

Adam você está incorreto. Ele afirma diretamente o quê e por quê.
ktamlyn

-5

Não é um caractere seguro e é usado para distinguir a porta à qual você se conecta quando está logo após seu nome de domínio

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.