En artículos anteriores hemos hablado de varios aspectos principales de la reescritura de URL. En el último artículo de esta serie, discutiremos algunos detalles y características de los diferentes niveles de reescritura de URL.
En teoría, la reescritura de URL de nivel IIS escrita en C o C++ tiene un rendimiento mayor que la reescritura de URL de nivel ASP.NET escrita en código administrado. Pero creo que la diferencia en esta área es insignificante en la mayoría de los casos y es casi imposible que este desempeño se convierta en un cuello de botella en el desempeño. Por lo tanto, el nivel de reescritura de URL elegido generalmente no está determinado por los requisitos de rendimiento de su aplicación. Entonces, ¿qué nivel de reescritura de URL se debe utilizar? Después de usar diferentes niveles de reescritura de URL, ¿a qué debemos prestar atención? Estoy aquí para hablar sobre mis puntos de vista personales.
Aunque el componente actual de reescritura de URL puede cumplir con la mayoría de las aplicaciones en términos de funcionalidad, en algún momento todavía necesitamos algunas funciones especiales. Por ejemplo, la reescritura de URL basada en el nombre de dominio no es fácil de lograr con el componente de reescritura de URL actual. El ISAPI Rewrite comercial actualmente puede soportar esto. Desafortunadamente, el código abierto UrlRewriter.NET y IIRF no tienen funciones suficientes a este respecto. Todos coinciden según la ruta de la solicitud relativa al sitio y el nombre de dominio solicitado no se puede utilizar como condición de coincidencia. Esto requiere que ampliemos el componente de reescritura de URL. Para la mayoría de los desarrolladores de .NET, el código administrado es, naturalmente, la primera opción para el desarrollo. En este momento, es posible que deba elegir el componente de reescritura de reescritura de URL de nivel ASP.NET. Sin embargo, se pueden encontrar muchos ejemplos de extensiones en Internet, ya sea UrlRewriter.NET en el nivel ASP.NET o IIRF en el nivel IIS.
Pero, de hecho, si queremos lograr las funciones anteriores, también podemos hacerlo en dos pasos. Primero usamos IIRF para la reescritura de URL en el nivel IIS y luego reescritura de URL en el nivel ASP.NET. Por ejemplo, si ahora queremos reescribir " http://jeffz.domain.com/articles " a "/ArticleList.aspx?owner=jeffz", primero podemos dejar que IIRF haga la primera reescritura de URL, con el propósito de reescribir " /articles" se reescribe como "/ArticleList.aspx".
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
De esta manera, el motor ASP.NET recibirá directamente una solicitud para /ArticleList.aspx. Luego, dentro de ASP.NET, podemos realizar la segunda reescritura de URL (por conveniencia, todavía la escribo en Global.asax y se recomienda usar HttpModule adicional en el proyecto).
void protegido Application_BeginRequest (remitente del objeto , EventArgs e)
{
Contexto HttpContext = HttpContext .Actual;
host de cadena = contexto.Request.Url.Host;
propietario de la cadena = host.Substring(0, host.IndexOf( '.' ));
contexto.RewritePath(context.Request.RawUrl + "?propietario=" + propietario);
}
Después de dos reescrituras de URL, se logra el efecto que queremos (en proyectos reales, el código anterior no se puede usar directamente porque es necesario juzgar si hay una cadena de consulta, etc.).
Además, la reescritura de URL de nivel ASP.NET solo puede funcionar en ASP.NET (algo obvio). Si desea que la reescritura de URL sea compatible con otras tecnologías de servidor como PHP, RoR, etc., solo puede usar la reescritura de URL de nivel IIS. (u otra función de reescritura de URL proporcionada por la tecnología del servidor).
Algunos caracteres especiales no pueden aparecer en las URL o, una vez que aparecen en las URL, el significado de la solicitud cambia. Por ejemplo, necesitamos realizar una reescritura de URL en la página de búsqueda, reescribir "/Search/xxx" a "/Search.aspx?xxx" y luego obtener las palabras clave proporcionadas por el usuario según la cadena después del signo de interrogación. Si usamos UrlRewriter.NET, usaremos la siguiente
configuración : <rewriter>
< reescribir URL = " ^/Buscar/(.+)$ " a = " ~/Buscar.aspx?$1 " procesamiento = " detener " />
</ rewriter >
En circunstancias normales, esta reescritura de URL funciona normalmente. Pero si el usuario utiliza "%" como palabra clave, la situación es diferente, porque recibiremos el siguiente mensaje en la página de error:
Esto se debe a que "%" no está permitido en la URL. Puede ir a varios sitios web e intentar solicitar algunas rutas como "ABC%25DEF" ("%25" va seguido de "%"), y la mayoría de ellos encontrará errores "400 Bad Request". Sin embargo, es legal poner "%" en la cadena de consulta. Sí, ¿no reescribimos la palabra clave en la cadena de consulta? ¿Por qué todavía no funciona? Esto también está determinado por la forma en que se ejecuta ASP.NET.
La solicitud incorrecta se determina en el paso 3 de la figura anterior, es decir, mientras aún se está inicializando. Nuestra reescritura de URL solo ocurre en el evento BeginRequest en el paso 4. Cuando la solicitud contiene caracteres ilegales, no tenemos ninguna posibilidad de realizar ninguna reescritura de URL.
Entonces, ¿cómo abordamos este problema? En circunstancias normales, no será un gran problema si eliminamos % en el cliente (algunos sitios hacen esto), pero ¿qué pasa si tenemos que conservarlo? Luego use Query String para pasar parámetros, o también podemos usar la reescritura de URL a nivel de IIS. Siguiendo tomando IIRF como ejemplo:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
Cuando la solicitud se envía a IIS (paso 1), y después de seleccionar qué ISAPI se debe entregar terminado para su ejecución (Paso 2) La reescritura de URL se produjo antes. Después de la reescritura de URL, el "%" en la dirección se transfirió a la cadena de consulta y, naturalmente, es legal cuando se entrega a ASP.NET para su procesamiento.
Finalmente, analicemos la configuración de la página de error. Por ejemplo, generalmente configuraremos una página de error 404 para la aplicación, de modo que cuando el usuario acceda a un recurso inexistente, podamos mostrarle una página específica en lugar del mensaje de error predeterminado. Pero en este punto, se deben configurar diferentes niveles de reescritura de URL utilizando diferentes métodos.
Si utilizamos la reescritura de URL a nivel de ASP.NET, en términos generales hemos configurado el mapeo comodín en IIS, de modo que cualquier solicitud (incluidos html, jpg, etc.) será procesada por ASP.NET. Si se solicita un recurso que no existe, ASP.NET emitirá un error 404, por lo que la página de error 404 debe configurarse en web.config:
< customErrors modo = " Activado " defaultRedirect = " GenericErrorPage.htm " >
< error código de estado = " 404 " redirigir = " FileNotFound.htm " />
</ customErrors >
Si utilizamos la reescritura de URL de nivel IIS, no configuraremos la asignación de comodines. En otras palabras, el motor ASP.NET solo comenzará a funcionar cuando la dirección después de Reescribir sea aspx (u otras cosas que deberían haber sido manejadas por ASP.NET ISAPI). Si el usuario solicita un recurso que no existe, IIS emitirá un error 404. En este momento, la página de error 404 debe configurarse en IIS:
Hasta ahora, se ha discutido el tema de la reescritura de URL. En el desarrollo real, definitivamente encontrará varias situaciones diferentes, pero siempre que comprenda la clave del método de reescritura de URL y piense de acuerdo con la forma en que se ejecuta el programa, creo que generalmente no encontrará problemas difíciles.