url - metatags - meta name keywords

Es un colon `:` seguro para el uso amigable de URL?

Question

Estamos diseñando un sistema de URL que especificará las secciones de la aplicación como palabras separadas por barras. Específicamente, esto está en GWT, por lo que las partes relevantes de la URL estarán en el hash (que será interpretado por una capa de controlador en el lado del cliente):

http://site/gwturl#section1/section2

Algunas secciones pueden necesitar atributos adicionales, que nos gustaría especificar con un : modo que las partes de la sección de la URL no sean ambiguas. El código se dividiría primero en / y luego en : esta manera:

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

Por supuesto, estamos haciendo esto para la compatibilidad con la url, por lo que nos gustaría asegurarnos de que ninguno de estos caracteres que tengan un significado especial sea codificado en URL por los navegadores, o cualquier otro sistema, y ​​terminan con una url como esta:

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

¿Utilizar los dos puntos de este modo es seguro (con lo que quiero decir que no se codificará automáticamente) para navegadores, sistemas de marcadores, incluso código JavaScript o Java?

Answer 1

Además del análisis de McDowell sobre el estándar URI, recuerde también que el fragmento debe ser un nombre de ancla HTML válido. De acuerdo con http://www.w3.org/TR/html4/types.html#type-name

Los tokens de ID y NAME deben comenzar con una letra ([A-Za-z]) y pueden ir seguidos de cualquier cantidad de letras, dígitos ([0-9]), guiones ("-"), guiones bajos ("_") , dos puntos (":") y puntos (".").

Entonces estás de suerte. ":" está explícitamente permitido. Y nadie debería "%" - escapar, no solo porque "%" es ilegal char allí, sino también porque el fragmento coincide mucho con el nombre de anclaje char-by-char, por lo tanto, ningún agente debe tratar de atenuarse con ellos de todos modos.

Sin embargo, debes probarlo. Los estándares web no se siguen estrictamente, a veces los estándares son contradictorios. Por ejemplo, HTTP / 1.1 RFC 2616 no permite la cadena de consulta en la URL de solicitud, mientras que HTML construye una al enviar un formulario con el método GET. Cualquiera que sea implementado en el mundo real gana al final del día.

Answer 2

Colon no es seguro. Mira aquí

Answer 3

Desde URLEncoder javadoc:

Para obtener más información sobre la codificación de formularios HTML, consulte la specification HTML.

Al codificar una Cadena, se aplican las siguientes reglas:

• Los caracteres alfanuméricos "a" a "z", "A" a "Z" y "0" a "9" siguen siendo los mismos.
• Los caracteres especiales ".", "-", "*" y "_" siguen siendo los mismos.
• El carácter de espacio "" se convierte en un signo más "+".
• Todos los demás caracteres son inseguros y se convierten primero en uno o más bytes utilizando algún esquema de codificación. Entonces cada byte se representa con la cadena de 3 caracteres "% xy", donde xy es la representación hexadecimal de dos dígitos del byte. El esquema de codificación recomendado para usar es UTF-8. Sin embargo, por razones de compatibilidad, si no se especifica una codificación, entonces se utiliza la codificación predeterminada de la plataforma.

Es decir,: no es seguro.

Answer 4

Los puntos se usan como la división entre el nombre de usuario y la contraseña si un protocolo requiere autenticación.

Answer 5

MediaWiki y otros motores de wiki usan dos puntos en sus URL para designar espacios de nombres, aparentemente sin mayores problemas.

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

Answer 6

No contaría con eso. Es probable que muchos usuarios-agente lo codifiquen como %3A .

Answer 7

No es un carácter seguro y se usa para distinguir a qué puerto se conecta cuando está justo después de su nombre de dominio.

Answer 8

No veo que Firefox o IE8 codifiquen algunas de las URLs Wikipedia que incluyen el personaje.

Answer 9

Recientemente wrote un codificador URL, así que esto es bastante fresco en mi mente.

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

Todos los personajes en la parte del fragmento ( user:45/comments ) son perfectamente legales para RFC 3986 URI.

Las partes relevantes del ABNF :

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

Además de estas restricciones, la parte del fragmento no tiene una estructura definida más allá de la que le da su aplicación. El esquema, http, solo dice que no envía esta parte al servidor.

EDITAR:

D''oh!

A pesar de mis afirmaciones sobre la especificación de URI, irreputable proporciona la respuesta correcta cuando señala que la especificación de HTML 4 restringe los nombres / identificadores de los elementos .

Tenga en cuenta que las reglas de identificación están cambiando en HTML 5 . Las restricciones de URI se seguirán aplicando (al momento de escribir, hay algunos problemas sin resolver sobre el uso de URI por parte de HTML 5).