¿Cuándo debe codificarse un asterisco en una URL HTTP?

url-encoding rfc

Question

Según RFC1738 , un asterisco (*) "se puede usar sin codificar dentro de una URL":

Por lo tanto, solo los caracteres alfanuméricos, los caracteres especiales "$ -_. +! * ''()," Y los caracteres reservados utilizados para sus fines reservados pueden usarse sin codificar dentro de una URL.

Sin embargo, el material de Denominación y direccionamiento de w3.org dice que el asterisco está "reservado para su uso por tener una significación especial dentro de esquemas específicos" e implica que debería estar codificado.

Además, de acuerdo con RFC3986 , una URL es una URI:

El término "Localizador uniforme de recursos" (URL) se refiere al subconjunto de URI que, además de identificar un recurso, proporciona un medio para ubicar el recurso al describir su mecanismo de acceso primario (por ejemplo, su "ubicación" de red).

También especifica que el asterisco es un "sub-delim", que forma parte del "conjunto reservado" y:

Las aplicaciones que producen URI deben codificar en porcentaje los octetos de datos que corresponden a los caracteres en el conjunto reservado, a menos que el esquema de URI permita específicamente que estos caracteres representen los datos en ese componente.

También especifica explícitamente que actualiza RFC1738 .

Leí que todo esto requiere que los asteriscos estén codificados en una URL a menos que se usen para un propósito especial definido por el esquema URI.

¿Es RFC1738 la referencia canónica para el esquema de URI de HTTP? ¿De alguna manera exime al asterisco de la codificación, o es obsoleto en ese sentido debido a RFC3986 ?

Wikipedia dice que "[t] el personaje no necesita estar codificado en porcentaje cuando no tiene un propósito reservado". ¿El RFC1738 elimina el propósito reservado del asterisco?

Varios recursos y herramientas parecen divididos en esta pregunta.

El urlencode y rawurlencode , el último de los cuales pretende seguir RFC3986 , codifica el asterisco .

Sin embargo, el escape de JavaScript y encodeURIComponent no codifican el asterisco .

Y URLEncoder de Java no codifica el asterisco :

Los caracteres especiales ".", "-", "*" y "_" siguen siendo los mismos.

Las tools populares en online (dos resultados principales para una búsqueda en Google de "codificador de url en línea" ) tampoco codifican el asterisco. La tools indica específicamente que "[e] l los caracteres reservados deben codificarse solo bajo ciertas circunstancias". Continúa enumerando el asterisco y el símbolo y como caracteres reservados. Codifica el signo y no el asterisco.

Otras preguntas similares en la comunidad de Stack Exchange parecen tener respuestas obsoletas, incompletas o poco convincentes:

• urlencode () el carácter ''asterisco'' (¿estrella?) Esta pregunta resalta las diferencias entre el tratamiento de asterisco de Java y PHP y pregunta cuál es "correcto". La respuesta aceptada solo hace referencia al RFC1738 , sin mencionar el RFC3986 más reciente y resolviendo el conflicto. Otra respuesta reconoce la discrepancia y sugiere que los asteriscos son diferentes para las URL específicamente, a diferencia de otros URI, pero no proporciona autoridad específica para esa conclusión.
• ¿Puede una URL tener un asterisco? Una respuesta cita solo el antiguo RFC1738 y la respuesta aceptada implica que es aceptable cuando se usa como un delimitador, lo que se supone es el "propósito reservado".
• ¿Puedo usar asteriscos en las URL? La respuesta aceptada parece desalentar el uso del asterisco sin aclarar las reglas que rigen el uso. Otra respuesta dice que puedes usar el asterisco "porque es un carácter reservado". ¿Pero no es eso solo cierto si lo está utilizando para su propósito reservado?
• escape de caracteres especiales en una url Una respuesta señala que "existe cierta ambigüedad sobre si un asterisco debe codificarse en una URL". Estoy tratando de resolver esa ambigüedad con esta pregunta.
• Spring UriUtils y RFC3986 Esta pregunta señala que encodeQueryParam de encodeQueryParam pretende seguir RFC3986 , pero no codifica el asterisco. No hay respuestas a esa pregunta a partir del 2014-08-01 12:50 PM CDT.
• ¿Cómo codificar una URL en JavaScript? Esta parece ser la pregunta de codificación de la URL de JavaScript canónica en Stack Overflow, y aunque las respuestas señalan que los asteriscos están excluidos de los diversos métodos, no abordan si deberían serlo.

Con todo esto en mente, ¿cuándo se debe codificar un asterisco en una URL HTTP?

Answer 1

Respuesta corta

La definición actual de sintaxis de URL indica que nunca necesita codificar en porcentaje el carácter de asterisco en la ruta, la consulta o los componentes de fragmentos de una URL.

HTTP 1.1

Como señaló @Riley Major, el RFC indica que las referencias HTTP 1.1 para la sintaxis de la URL han quedado obsoletas con el RFC3986 , que no es tan blanco y negro sobre el uso de asteriscos como el RFC originalmente referenciado.

RFC2396 (especificación de URL antes de enero de 2005 - respuesta original)

Un asterisco nunca necesita estar codificado en las URL de HTTP 1.1 ya que * aparece como un "carácter no RFC2396 " en RFC2396 , que se utiliza para definir la sintaxis de URI en HTTP 1.1. Se permiten caracteres no reservados en el componente de ruta de una URL .

2.3. Personajes sin reserva

Los caracteres de datos que están permitidos en un URI pero que no tienen un propósito reservado se llaman no reservados. Estos incluyen letras mayúsculas y minúsculas, dígitos decimales y un conjunto limitado de signos de puntuación y símbolos.

 unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "''" | "(" | ")"

Los caracteres no reservados pueden escaparse sin cambiar la semántica de la URI, pero esto no se debe hacer a menos que la URI se utilice en un contexto que no permita que aparezca el carácter no escapado.

RFC3986 (sintaxis de URL actual para HTTP)

RFC3986 modifica RFC2396 para hacer que el asterisco sea un carácter reservado, con el motivo de que es "generalmente inseguro descifrar". Mi comprensión de este RFC es que el carácter de asterisco no codificado está permitido en los componentes de ruta, consulta y fragmento de una URL, ya que estos componentes no especifican el asterisco como un delimitador ( 2.2. Caracteres reservados ):

Estos caracteres se denominan "reservados" porque la sintaxis genérica los puede definir (o no) como delimitadores ... Si los datos de un componente URI entran en conflicto con el propósito de un carácter reservado como delimitador, entonces los datos en conflicto deben ser porcentuales. -codificado antes de que se forme la URI

Además, 3.3 Path confirma que un subconjunto de caracteres reservados ( sub-delims ) se puede usar sin codificar en segmentos de ruta (partes del componente de ruta divididas por / ):

Aparte de los segmentos de punto ("." Y "..") en las rutas jerárquicas, un segmento de ruta se considera opaco por la sintaxis genérica. Las aplicaciones que producen URI a menudo usan los caracteres reservados permitidos en un segmento. ... Por ejemplo, los caracteres reservados de punto y coma (";") y iguales ("=") a menudo se usan para delimitar parámetros y valores de parámetros aplicables a ese segmento. El carácter reservado con coma (",") se utiliza a menudo para fines similares. Por ejemplo, un productor de URI podría usar un segmento como "nombre; v = 1.1" para indicar una referencia a la versión 1.1 de "nombre", mientras que otro podría usar un segmento como "nombre, 1.1" para indicar lo mismo.

HTTP 1.0

HTTP 1.0 hace referencia al RFC1738 para definir la sintaxis de URL, que a través de una serie de actualizaciones y obsoletos significa que utiliza el mismo RFC que HTTP 1.1 para la sintaxis de URL.

En cuanto a la compatibilidad con versiones anteriores, RFC1738 especifica el asterisco como un carácter reservado, aunque HTTP 1.0 no define ningún significado especial para un asterisco no codificado en el componente de ruta de una URL, no debería romper nada si usa uno. . Esto debería significar que todavía estás a salvo poniendo asteriscos en las URL que apuntan a los sistemas más antiguos.

Como nota al margen, el carácter de asterisco tiene un significado especial en un Request-URI en ambas especificaciones HTTP, pero no es posible representarlo con una URL HTTP:

El asterisco "*" significa que la solicitud no se aplica a un recurso en particular, sino al propio servidor, y solo se permite cuando el método utilizado no se aplica necesariamente a un recurso. Un ejemplo sería

 OPTIONS * HTTP/1.1

Descargo de responsabilidad: solo estoy leyendo e interpretando estos RFC, por lo que puedo estar equivocado.