nginx - keywords - meta tags html seo
Modificar respuesta HTML(no encabezados) (3)
Esto parece ser posible a través de una serie de enfoques diferentes, pero eso no quiere decir lo conveniente que podría ser en realidad.
Parece potencialmente problemático (ejemplo: ¿qué pasa si reescribes algo que no debería haber sido reescrito?) Y requiere muchos recursos de la máquina (muchos ciclos de CPU para analizar y munge cuerpos de respuesta, repetidamente).
Esto es lo que encontré:
Nginx tiene el http_sub_module que parece lograr esto de una manera bastante sencilla, asumiendo que lo que quiere reemplazar es simple y solo necesita hacer coincidir un patrón por página, como reemplazar <a href="http://example.com/... con <a href="https://example.com/... , una o más veces. Este tipo de contenido-mungery parece incompleto, pero dependiendo de la situación en la que se encuentre (lo que puede ser uno de control limitado de la aplicación) puede llevarlo allí.
Parece que hay algo llamado http_substitutions_filter , posiblemente no oficial o al menos no parte de la distribución Nginx del núcleo que puede hacer una reescritura de cuerpos de respuesta más poderosa basada en filtros.
El barniz parece tener una capacidad similar (posiblemente un complemento) pero HAProxy doesn''t , ya que solo se ocupa de los encabezados y deja los cuerpos solos, excepto cuando se realiza la descarga de gzip. Otro software con capacidad de proxy inverso como Apache o Squid también podría ofrecer algo útil, que colocaría frente a su servidor de aplicaciones.
Mi impresión inicial, en cualquier caso, es que la simple sustitución de cadenas puede que no te lleve hasta allí, e incluso la sustitución basada en expresiones regulares no es suficiente, sin una sofisticación significativa en las expresiones regulares, porque siempre corres el riesgo de volver a escribir algo que no deberia
Lo que sugeriría "realmente tiene que suceder" para lograr este propósito de la manera más correcta, sería interpretar el HTML generado con una biblioteca de análisis DOM, atravesar el árbol y modificar los elementos relevantes en el lugar, antes de Entregando el documento revisado al solicitante. De esta manera, el documento se modifica en función de una comprensión contextual de sus contenidos.
Suena complicado, en mi opinión, porque lo es, por lo que le sugeriría que reconsidere su enfoque planificado a menos que esté fuera de su control.
Reflexión final: la curiosidad consiguió lo mejor de mí, así que tomé esta pregunta y actualicé el proxy inverso http que escribí (para un propósito diferente) para que, en función del tipo de contenido, realmente pudiera analizar y recorrer la estructura HTML como un entidad apropiada, modificándola en su lugar (como se describe anteriormente), antes de devolver el cuerpo de respuesta al solicitante.
Esto resulta, como esperaba, que requiere bastante uso del procesador. El contenido de mi prueba fue de 29 K de HTML real de un sitio en vivo, con 56 elementos <a href ...> y 6 <link rel ...> , y la operación de reescritura requirió 128 ms en un Opteron 1218 de 1 GHz. y 43 ms Xeon E5620 a 2.4GHz. Estos puntos de referencia son estrictamente para las operaciones adicionales, excluyendo el tiempo (menor cantidad de) requerido para la propia funcionalidad de "proxy". Este costo de tiempo no es insuperable, pero podría sumar una gran cantidad de tiempo de CPU. Esto es mucho más largo de lo que llevaría una reescritura de contenido basada en expresiones regulares, pero es mucho más preciso y es poco probable que rompa las páginas que toca.
Esperar que alguien me pueda ayudar o que me indique la dirección correcta.
Me han pedido que averigüe cómo hacer que Akamai (o cualquier otro CDN, o NGINX) modifique el cuerpo de respuesta real.
¿Por qué?
Tengo que hacer que el CDN cambie todas las solicitudes "http: //" a "https: //" en lugar de modificar el código de la aplicación para usar "//" para las solicitudes de recursos externos.
es posible?
¿Nadie sabe?
HttpSubsModule de Nginx funcionó muy bien para mí: http://wiki.nginx.org/HttpSubsModule
Cambiar de http a https debería ser tan simple como esto:
location / {
subs_filter_types text/html text/css text/xml;
subs_filter http.example.com https.example.com gi;
}
Igual pero la sintaxis correcta.
location / {
sub_filter_types text/html text/css text/xml;
sub_filter ''http.example.com'' ''https.example.com'';
}