HTTP URL - caracteres permitidos en los nombres de los parámetros

¿Existe alguna restricción formal sobre qué caracteres están permitidos en los nombres de parámetros de URL?HTTP URL - caracteres permitidos en los nombres de los parámetros

He estado leyendo RFC3986 ("Uniform Resource Identifier (URI): Generic Syntax") pero no he llegado a una conclusión definitiva.

Sé que hay limitaciones prácticas, sino que en realidad se prohibirá a hacer algo como:

param with\funny<chars>=some_value

, siempre y cuando me escape correctamente:

caracteres

param%20with%1cfunny%3cchars%3e=some_value

Fuente

2009-05-02 Tomalak

No hay restricciones para los nombres de parámetros escapados en las especificaciones de URI. Sin embargo, puede haber restricciones en el software del lado del servidor que use. Esto es especialmente cierto si usa scripts "caseros" para interpretar URI.

Fuente

2009-05-02 11:38:49

Es exactamente por eso que he estado preguntando ... http://stackoverflow.com/questions/814613/how-to-read-data-from-url-using-javascript - Creo que mi respuesta necesitaría una revisar para corregirlo en situaciones inusuales. – Tomalak

Ah, eso complica la situación sustancialmente. Especialmente desde que usar '&' como delimitador es solo una convención; otros podrían ser utilizados en su lugar, p. ',' y ';' solían usarse bastante. Además, muchos motores de servidor (PHP, Rails, ...) admiten argumentos anidados, por lo que este sería un URI legal con consulta: http://example.com/?a=b;c[1]=x;c[2] = y ... Muchas aplicaciones web realmente usan esta notación de consulta para datos de formulario (opciones, casillas de verificación ...) para obtener datos parecidos a un array. –

Así que supongo que se reduce a "no hay una única función correcta para extraer los parámetros de una URL", a menos que esté dispuesto a aceptar que "c [1] = x" es una convención del lado del servidor, y el parámetro lo que está buscando * de hecho * se llama "c [1]" en el cliente (lo que sería correcto en cuanto a los hechos, pero resultará extraño para los que están acostumbrados a la programación del lado del servidor ...). – Tomalak

No están reservados para las direcciones URL , pero mientras escape (urlencode), entonces debería estar bien.

Según el marco utilizado, puede obtener excepciones si intenta enviar valores sospechosos. ASP.NET tiene un filtrado de contenido que arrojará excepciones si intentas enviar datos "inseguros", como scripts o HTML. Esa es una característica del marco, más que una limitación o regla impuesta por la sintaxis de la URL.

Fuente

2009-05-02 11:37:16

También debería leer RFC2396. Parece ser más informativo que RFC3986.

Fuente

2009-05-02 12:16:45

Sección 3.4. ("Componente de consulta"): "El componente de consulta es una cadena de información que debe interpretar el recurso". Esto básicamente significaría "todo vale", tal como yo pensaba. – Tomalak

Desafortunadamente no es HTTP específico. Pero supongo que no hay un estándar aquí, solo una convención. – Tomalak

HTTP URL - caracteres permitidos en los nombres de los parámetros

Respuesta

Cuestiones relacionadas