tag route pass parameter page net mvc data asp all asp.net iis url url-rewriting

asp.net - route - href mvc razor



¿Puedo usar comas en una URL? (8)

Normalmente utilizo la reescritura de URL para pasar identificaciones de contenido a mi sitio web, por lo que este

Foo.1.aspx

reescribe para

Foo.aspx?id=1

Para una aplicación específica, necesito pasar múltiples identificadores a una sola página, así que he reescrito cosas para aceptar esto:

Foo.1,2,3,4,5.aspx

Esto funciona bien en Cassini (el servidor web ad hoc incorporado para Visual Studio) pero me da "Internet Explorer no puede mostrar la página web" cuando lo pruebo en un servidor en vivo que ejecuta IIS. ¿Es esto una limitación de IIS? ¿Debo usar guiones o guiones bajos en lugar de comas?


Responder

El problema fueron las comas. Supongo que IIS estaba teniendo un problema (no IE) ya que IE podía mostrarlo bien en localhost.

En cualquier caso, acabo de cambiar el formato de URL a esto y funciona bien:

Foo.1-2-3-4-5.aspx


Además de la respuesta de ConroyP, a continuación hay otra cita del RFC. Nota una serie de caracteres inseguros, pero no menciona la coma (lo que sugiere que la coma es segura):

Los personajes pueden ser inseguros por varias razones. El carácter de espacio no es seguro porque los espacios significativos pueden desaparecer y se pueden introducir espacios insignificantes cuando las URL se transcriben o se compilan tipográficamente o se someten al tratamiento de programas de procesamiento de textos. Los caracteres "<" y ">" no son seguros porque se usan como delimitadores de las URL en texto libre; la marca de comillas ("" ") se utiliza para delimitar URL en algunos sistemas. El carácter" # "no es seguro y siempre debe codificarse porque se usa en World Wide Web y en otros sistemas para delimitar una URL de un fragmento / ancla. identificador que podría seguirlo. El carácter "%" no es seguro porque se usa para codificaciones de otros caracteres. Otros caracteres no son seguros porque se sabe que las puertas de enlace y otros agentes de transporte modifican a veces dichos caracteres. Estos caracteres son "{", "} "," | "," / "," ^ "," ~ "," [","] "y" `".

Todos los caracteres inseguros siempre deben estar codificados dentro de una URL. Por ejemplo, el carácter "#" debe estar codificado dentro de las URL, incluso en sistemas que normalmente no se ocupan de identificadores de fragmentos o anclajes, de modo que si la URL se copia en otro sistema que sí los utiliza, no será necesario cambiar el Codificación URL


Intenta usar %2c en la URL para reemplazar las comas.


La coma está permitida en la ruta, cadena de consulta y fragmento de acuerdo con la especificación. No me sorprendería si IE no se ajusta a la especificación. Prueba la entidad como sugiere Claudiu, pero no sé por qué sería necesario.


La forma correcta de aceptar múltiples ID es así:

Foo.aspx?id=1;id=2;id=3;id=4;id=5

Tenga en cuenta que es justo lo que es el objetivo. Al volver a escribir urls, puede establecer sus propias reglas hasta cierto punto para el aspecto que desea que tenga la fuente.

También tuve que aprender esto en . Ver esta pregunta:
Dividir los enteros de la cadena


Las comas están permitidas en el nombre de archivo de una URL, pero son caracteres reservados en el dominio *, hasta donde yo sé.

¿Qué versión de IE estás usando? He encontrado el informe impar de IE5.5 truncar URL en una coma ( enlace aquí , pero he probado URLs con comas en IE7 y parece estar bien, así que si había un error de IE, no parece estar allí más, ¿podría ser un problema de IIS?

Me pregunto si el error de la página se debe a una falla de la regla con el mod_rewrite . ¿Puedes publicar la regla que hace coincidir varios ID y pasarlos a tu Foo.aspx ? ¿Hay alguna posibilidad de que solo coincida Foo.N,N y fallar en más comas?

* Desde el URI RFC :

2.2. Caracteres reservados

Muchos URI incluyen componentes que consisten o están delimitados por ciertos caracteres especiales. Estos caracteres se llaman "reservados", ya que su uso dentro del componente URI está limitado a su propósito reservado. Si los datos de un componente URI entrarían en conflicto con el propósito reservado, entonces los datos en conflicto se deben escapar antes de formar el URI.

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

La clase de sintaxis "reservada" anterior se refiere a los caracteres que están permitidos dentro de un URI, pero que no pueden permitirse dentro de un componente particular de la sintaxis URI genérica.


Recuerdo que el enrutamiento de Url por defecto comprueba primero si el archivo existe, y las comas no son legales en los nombres de archivo, que es quizás la razón por la que está recibiendo errores. IIS puede tener un código heredado que cancela la solicitud antes de que pueda llegar a asp.net para su procesamiento.

La publicación del blog de Scott Hanselman habla un poco sobre esto y puede ser relevante para usted.

Como comentario general: la reescritura de URL normalmente se utiliza para hacer que una URL sea amigable y fácil de recordar.

~/page.aspx?id=1,2,3,4 no es peor ni mejor que ~/page/1-2-3-4.aspx : ambos son difíciles de usar, ¿por qué hacer el esfuerzo extra? Evita crear nuevas formas de url solo porque puedes. Los usuarios, el servicio de asistencia y otros desarrolladores se sentirán confundidos.

La reescritura de URL se utiliza mejor para transformar

~/products/view.aspx?id=1 ~/products/category.aspx?type=beverage

dentro

~/products/view/1 ~/products/category/beverage


Si pusieras un control frontal, podrías hacer algo como;

index.aspx?c=Foo/1/2/3/4

El controlador frontal seleccionará el nombre del método y los parámetros que se le pasarán. Esta es una técnica bastante común hoy en día.