¿Tiene una gran lista de redirección en .htaccess a Problem?

Question

Quiero redireccionar todos los redireccionamientos de publicaciones 301, pero tengo más de 3000 publicaciones.

Si enumero

Redirect permanent /blog/2010/07/post.html http://new.blog.com/2010/07/23/post/ 
Redirect permanent /blog/2010/07/post1.html http://new.blog.com/2010/07/24/post1/ 
Redirect permanent /blog/2010/07/post2.html http://new.blog.com/2010/07/25/post2/ 
Redirect permanent /blog/2010/07/post3.html http://new.blog.com/2010/07/26/post3/ 
Redirect per...... 

por más de 3.000 URL de redirección de comandos en este .htaccess sería comer mi recurso del servidor o causar algún problema? No estoy seguro de cómo funciona .htaccess, pero si el servidor está mirando estas listas cada vez que el usuario solicita una página, supongo que será un recurso de recursos.

No puedo usar RedirectMatch porque agregué la variable de fecha en mi nueva url. ¿Tiene alguna otra sugerencia que redirija estas publicaciones? ¿O estoy bien?

Gracias!

Answer 1

No soy un experto en Apache, por lo que no puedo decir si tener 3.000 redireccionamientos en .htaccess es un problema (aunque mi instinto me dice que probablemente sea una mala idea). Sin embargo, como una solución más simple a su problema, ¿por qué no usar mod_rewrite para hacer sus redireccionamientos?

RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/$3/ [R=permanent] 

Esto usa una expresión regular para que coincida con las URL antiguas y las reescriba a las nuevas. El [R=permanent] instruye a mod_rewrite para que emita un 301 con la nueva URL en lugar de volver a escribir silenciosamente la solicitud internamente.

En su ejemplo, parece que ha agregado el día de la publicación a la URL, que no existe en la URL anterior. Como obviamente no puedes usar una expresión regular para adivinar el día en que se realizó una publicación arbitraria, es posible que este método no funcione para ti. Si puede eliminar el día de la URL, entonces está listo para comenzar.

Editar: La primera vez que leí su pregunta, me perdí el último párrafo. ("No puedo usar RedirectMatch porque agregué la variable de fecha en mi nueva url.") En este caso, puede usar mod_rewrite's RewriteMap para buscar el componente de día de una publicación.

tiene dos opciones:

1. utilizar un HashMap para realizar búsquedas rápidas en un archivo estático. Esto significa que todas las URL anteriores funcionarán, pero no se puede acceder a ninguna publicación nueva utilizando el esquema de URL anterior.
2. Use una secuencia de comandos para tomar el día.

En la opción uno, crear un archivo llamado posts.txt y puso:

/yyyy/mm/pppp dd 

... para cada puesto donde aaaa es el año de la entrada, mm es el mes, y es pppp el nombre del poste (sin el .html).

Cuando haya terminado, ejecute:

$ httxt2dbm -i posts.txt -o posts.map 

luego añadimos a al servidor de configuración del servidor/virtual: (. Tenga en cuenta que el camino es un camino sistema de archivos, no una URL)

RewriteMap postday dbm:/path/to/file/posts.map 
RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/${postday:$1/$2/$3}/$3/ [R=permanent] 

En la opción dos, use pgm:/path/to/script/lookup.whatever como RewriteMap. Consulte mod_rewrite documentation para obtener más información sobre el uso de un script.

Hacer la búsqueda en mod_rewrite es mejor que simplemente redirigir a un script que busca la fecha y luego redirige al destino final porque you should never redirect more than once. La emisión de un 301 o 302 tiene un costo de ida y vuelta, lo que aumenta la latencia del tiempo de carga de la página.

Answer 2

Nunca es una buena idea hacer una lista masiva de Redirecciones. Una mejor técnica de programación es simplemente redirigir las páginas sin esa variable de fecha y luego tener un pequeño fragmento de PHP que detecta si falta y redirige a la URL con la que está incluida. La larga lista parece hortera y ralentiza a Apache porque está verificando esa URL (cualquier otra URL que pueda no verse afectada por esto) contra cada línea. Si solo fueran 5 o así, diría que está bien, pero 3,000 es un NO definitivo.

Aunque no soy un gran fan de este método, una mejor opción sería la de redirigir todas las URL normalmente utilizando una sola instrucción partido, lo redirecciona a la página sin la parte de fecha, o con un guión o algo, luego incluya un pequeño fragmento de PHP para verificar si la fecha es válida y, de no ser así, vuelva a escribir la ruta a la URL correctamente formada.

Honestamente, si no tenía esa parte allí antes, no la necesita ahora, y probablemente confundirá a los motores de búsqueda cambiando la URL de 3.000 publicaciones. Realmente no necesita una fecha en la URL, un buen título es mucho más significativo no solo para los usuarios, sino también para los motores de búsqueda, que un montón de números.

Answer 3

Si tiene alguna forma en el código para determinar el día de una publicación, puede generar la reescritura sobre la marcha. Puede configurar un patrón mod_rewrite, algo así como .html y configurar un front controller pattern para calcular la nueva URL desde el anterior y emitir el encabezado 301.

con PHP como un ejemplo:

$_SERVER['REQUEST_URI'] 

contendrá la URL solicitada y

header("Location: http://new.blog.com/$y/$m/$d/$title/",TRUE,301); 

enviará una redirección.

Answer 4

Eso es ... una gran cantidad de redireccionamientos. Pero lo primero que le diría, y probablemente lo único que pueda decirle sin calificación, es que debe realizar algunas pruebas y ver cómo son los tiempos de acceso para su blog, y también ver el uso de la CPU y la memoria del servidor. mientras lo haces Si son bastante bajos incluso con esa lista gigante de redireccionamientos, estás bien siempre y cuando tu blog no experimente un aumento repentino en el tráfico. (Sospecho fuertemente que las reescrituras de 3000 estarán desacelerando mucho a Apache)

Dicho esto, sugeriría la sugerencia de josh de reemplazar las redirecciones por algo dinámico. Como dijo animuson, si está dispuesto a abandonar el día de la URL, será fácil configurar una directiva RewriteRule para manejar la redirección. De lo contrario, podría hacerlo con un script PHP o, en general, con algún código en cualquier lenguaje de scripting que pueda (use). Si está utilizando uno de los populares motores de blogs, probablemente ya contenga código para hacerlo. Básicamente puede hacer algo como

RewriteRule .* /blog/index.php 

y simplemente dejar que el script PHP resuelva qué publicación se solicitó. Tiene acceso a la base de datos, por lo que podrá hacerlo, y luego puede mostrar la publicación directamente desde el script PHP o, para recuperar el comportamiento de redirección original, puede enviar un encabezado Location con la URL correcta.

Una alternativa sería usar RewriteMap, que le permite escribir un RewriteRule donde el destino está determinado por un programa o archivo de su elección en lugar de estar especificado directamente en el archivo de configuración. Como una opción, puede especificar un archivo de texto que contenga las URL antiguas y nuevas, y Apache se encargará de buscar en el archivo la línea apropiada para cualquier solicitud dada. Lea la documentación (vinculada arriba) para obtener todos los detalles. Mencionaré que esto no se usa con mucha frecuencia, y no estoy seguro de cuánto más rápido sería en comparación con 3000 redireccionamientos.

Último consejo: Apache puede ser significativamente más rápido si puede mover las directivas de configuración (como Redirect) al servidor o al archivo de configuración del host virtual, y desactivar la lectura de .htaccess por completo. Supongo que mover 3000 directivas de .htaccess a la configuración del host virtual podría hacer que tu servidor sea considerablemente más rápido. Pero incluso mover las directivas en el archivo de configuración de vhost probablemente no produciría tanta aceleración como el uso de un solo RewriteRule.