¿Son los dos puntos `:` seguros para el uso de URL amigables?

109

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 :, para que las partes de la sección de la URL no sean ambiguas. El código se dividiría primero /y luego :, así:

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

Por supuesto, estamos haciendo esto para facilitar 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 ​​termine con una URL como esta:

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

¿Es seguro usar los dos puntos de esta manera (con lo que quiero decir que no se codificará automáticamente) para navegadores, sistemas de marcadores, incluso código Javascript o Java?

Nicole
fuente
¿Quizás sea una buena idea especificar (más claramente) que usa las URL solo en el lado del cliente? Dado que muchas de las respuestas (como la mía) parecen asumir que va a enviar la URL a un servidor utilizando HTTP.
Veger
Editado para aclarar que el uso del fragmento está ocurriendo en el lado del cliente.
Nicole
Tengo curiosidad: después de 10 meses, ¿te ha funcionado este esquema de URL? Estoy considerando usar el mismo esquema.
Jonathan Swinney
1
@Jonathan Swinney, Desafortunadamente, he dejado este proyecto (y compañía), aunque las respuestas aquí me convencieron de que es el camino a seguir. Si tuviera que iniciar un nuevo proyecto, usaría este esquema, pero también me aseguraría de usarlo #!para indicar que las páginas tienen estado; consulte googlewebmastercentral.blogspot.com/2009/10/… (Esta propuesta se ha adherido a por grandes usuarios de AJAX como Facebook)
Nicole
Acabo de descubrir que WhatsApp cortará una URL en los primeros dos puntos, por lo que, por ejemplo, inutilizó una URL de Google Maps. Entonces sí, es importante escapar.
Petruza

Respuestas:

84

Recientemente escribí un codificador de URL, por lo que esto está bastante fresco en mi mente.

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

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

Las partes relevantes de la ABNF :

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

Aparte 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íe esta parte al servidor.


EDITAR:

¡Oh!

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

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

McDowell
fuente
Creo que estás en algo, ¿puedes explicar esto un poco más? No enviar esto al servidor no es un problema, ya que estamos usando GWT. Simplemente no estoy seguro de tener claro la sintaxis especificada por la sección que citó.
Nicole
Pero :es un gen-delim, no un sub-delim.
bobince
1
El punto y coma es legal para un pchar, por lo que si está en sub-delim o gen-delim no es un problema
Veger
@bobince: :está en pchar, que está en fragment, por lo que :está permitido. @Renesis - Wikipedia tiene un artículo sobre ABNF en.wikipedia.org/wiki/ABNF Básicamente, estás viendo una lista de caracteres permitidos, donde /significa OR . No he realizado ninguna programación de GWT, por lo que no sé cómo usa la parte de fragmento de los URI.
McDowell
Una última pregunta: ¿tiene alguna idea de la aplicación en el mundo real de esta especificación? ¿Significa esto que los navegadores deberían / ​​ignorarán (omitirán la codificación) :en el fragmento?
Nicole
59

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

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

Así que estás de suerte. ":" está explícitamente permitido. Y nadie debería "%" - escapar de él, no sólo porque "%" es un carácter ilegal allí, sino también porque el fragmento debe coincidir con el nombre del ancla char-by-char, por lo que ningún agente debería intentar manipularlos de ninguna manera.

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

irrefutable
fuente
58

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

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

Paul Wray
fuente
31
Respuesta más relevante. Todos sabemos que lo que contienen las especificaciones tiene poco que ver con la realidad en el desarrollo web. No obtendrá una garantía de "seguridad" mucho mejor que "uno de los 10 mejores sitios web del mundo".
Steven Collins
1
@StevenCollins No es más relevante que la respuesta dada 3 años antes de esta que dice exactamente lo mismo :)
Martin James
7

No contaría con eso. Es probable que obtenga la URL codificada como %3Apor muchos agentes de usuario.

Asaf
fuente
1
@arbales: Sí. Algunos agentes de usuario menos compatibles dejarán las URL no compatibles sin adornos.
Asaph
4

Desde URLEncoderjavadoc:

Para obtener más información sobre la codificación de formularios HTML, consulte la especificación 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 no son seguros y primero se convierten en uno o más bytes utilizando algún esquema de codificación. Luego, cada byte está representado por 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, se utiliza la codificación predeterminada de la plataforma.

Es decir, :no es seguro.

axtavt
fuente
3

No veo que Firefox o IE8 codifiquen algunas de las URL de Wikipedia que incluyen el carácter.

kprobst
fuente
1
Opera también mantiene el punto y coma, pero contar con tal comportamiento no es algo bueno que se puede hacer
Veger
1
Renesis está hablando del fragmento de URL y no de la ruta de la URL.
Gumbo
Wikipedia fue uno de mis pensamientos al escribir esta pregunta. Entonces, ¿es técnicamente inválido / inseguro el uso de dos puntos? Normalmente veo (y) en Wikipedia las URL codificadas, pero nunca los dos puntos, lo que me dejó un poco confundido.
Nicole
3
La Wayback Machine tiene: en muchos de sus enlaces, por ejemplo, web.archive.org/web/20080822150704/http://stackoverflow.com
barrowc
2

Los dos puntos se utilizan para dividir el nombre de usuario y la contraseña si un protocolo requiere autenticación.

JP Silvashy
fuente
0

Colon no está seguro. Mira aquí

Beto
fuente
Esa página no motiva por qué no son seguras. El RFC2396 referenciado tampoco dice que deba escaparse. Además, el script de conversión proporcionado no lo codifica (en Chrome 9 de todos modos).
Adam Lindberg
Adán, estás equivocado. Dice directamente qué y por qué.
ktamlyn
-5

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.

RHicke
fuente