¿Cómo controlar el barniz y un navegador usando Cache-Control: encabezado de máxima edad en un entorno Rails?

Question

Recientemente agregué una instancia de Varnish a una pila de aplicaciones de Rails. Barniz en su configuración por defecto puede estar convencido de almacenamiento en caché de un determinado recurso mediante el encabezado Cache-Control, así:

Cache-Control: max-age=86400, public=true 

que logra que uno utilizando la sentencia expires_in en mis controladores:

def index 
    expires_in 24.hours, public: true 
    respond_with 'some content' 
end 

que funcionó bien. Lo que no esperaba es que el encabezado Cache-Control TAMBIÉN afecte al navegador. Eso lleva al problema de que ambos: Barniz y el navegador de mis usuarios almacenan en caché un cierto recurso. El recurso se depura del barniz correctamente, pero el navegador no intenta volver a solicitarlo a menos que se alcance la edad máxima.

Entonces me pregunto si debería usar 'expires_in' en combinación con Varnish en absoluto? Podría filtrar el encabezado Cache-Control en una instancia de Nginx o Apache frente a Varnish, pero parece extraño.

¿Alguien puede aclararme?

Saludos Felix

Answer 1

que en realidad es una pregunta muy buena y válida, y uno muy común con los proxies inversos.

El problema es que solo hay una propiedad de control de caché y está destinada al navegador del cliente (caché privada) y/o un servidor proxy (caché compartida). Si no desea que los servidores proxy de terceros guarden en caché su contenido, y desea que cada solicitud sea atendida por su barniz (o por su servidor Rails), debe enviar el encabezado de control de caché apropiado de Varnish.

cabecera Cache-Control Modificación enviada por el servidor se discute en detalle en https://www.varnish-cache.org/trac/wiki/VCLExampleLongerCaching

Usted puede acercarse a la solución desde dos ángulos diferentes. Si desea definir max-age en el back-end de Rails, por ejemplo, para especificar TTL diferentes para diferentes objetos, puede usar el método descrito en el enlace anterior.

Otra solución es no enviar encabezados de control de caché desde el back-end, y en su lugar definir los TTL deseables para los objetos en barniz vcl_fetch(). Este es el enfoque que hemos tomado.

Tenemos un TTL predeterminado de 600 segundos en Varnish y definimos TTL más largos para las páginas que definitivamente se purgan explícitamente cuando se realizan cambios. Aquí está nuestra vcl_fetch actual() definición:

sub vcl_fetch { 
    if (req.http.Host ~ "(forum|discus)") { 
    # Forum pages are purged explicitly, so cache them for 48h 
    set beresp.ttl = 48h; 
    } 

    if (req.url ~ "^/software/") { 
    # Software pages are purged explicitly, so cache them for 48h 
    set beresp.ttl = 48h; 
    } 

    if (req.url ~ "^/search/forum_search_results") { 
    # We don't want forum search results to be cached for longer than 5 minutes 
    set beresp.ttl = 300s; 
    } 

    if(req.url == "/robots.txt") { 
    # Robots.txt is updated rarely and should be cached for 4 days 
    # Purge manually as required 
    set beresp.ttl = 96h; 
    } 

    if(beresp.status == 404) { 
    # Cache 404 responses for 15 seconds 
    set beresp.http.Cache-Control = "max-age=15"; 
    set beresp.ttl = 15s; 
    set beresp.grace = 15s; 
    } 
} 

En nuestro caso no enviamos encabezados Cache-Control en absoluto de los servidores back-end web.