2011-01-21 13 views
18

tengo un recurso en mi Nginx que está configurado de esta manera:Cabeceras de control de caché repetidas; válido o no? (Nginx)

location ~ foo\.js$ { 
    add_header Cache-Control public; 
    expires 1d; 
} 

Si abro esto con Firebug y mirar las cabeceras que muestra esto:

Cache-Control max-age=86400, public 

El el sitio está usando HTTPS, así que quiero asegurarme de que lo hago bien porque aparentemente los navegadores no lo almacenan en la memoria caché a menos que sea de edad máxima> 0 AND public. See this

¿Pero qué sucede con mi Nginx cuando uso curl -Ik https://... es que dice:

... 
Expires: Sat, 22 Jan 2011 18:23:36 GMT 
Cache-Control: max-age=86400 
Cache-Control: public 
... 

Se repite el encabezado Cache-Control! Claramente Firebug no le importa. Pero es correcto?

¿Existe alguna forma mejor de establecer Expires y Cache-Control (con public) en solo dos líneas?

+0

¿Estás seguro de que necesitas un máximo de edad y público? De acuerdo con la especificación (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), la sección 14.9.3 establece que "La directiva de máximo de edad en una respuesta implica que la respuesta es almacenable en caché (es decir, "public"), a menos que exista alguna otra directiva de caché más restrictiva. " – herbrandson

Respuesta

24

Sí, es válido y equivalente para usar múltiples encabezados de Control de caché.

De los HTTP 1.1 spec:

campos de mensaje de encabezado múltiple con el mismo nombre de campo puede estar presente en un mensaje si y sólo si la totalidad campo-valor para ese campo de cabecera es define como una lista separada por comas [es decir, # (valores)]. TIENE que ser posible para combinar los múltiples campos de cabecera en uno "-nombre de campo: campo-valor" par, sin cambiar la semántica del mensaje, añadiendo cada subsiguiente campo-valor a la primera, cada uno separado por una coma

Es fácil verificar que esta disposición se aplica a la cabecera Cache-Control, debido a how it's defined:

Cache-Control = "Cache-Control" ":" 1 # caché directiva

Para comprender cómo interpretar la línea anterior, consulte la especificación notational conventions. El 1# significa "una lista separada por comas de uno o más".

+1

Por lo tanto, es válida en función de la especificación HTTP, pero la verdadera pregunta es ¿cómo manejan los buscadores y servidores proxy populares múltiples encabezados de Cache-Control? último y mejor, probablemente lo maneje correctamente, pero Firefox, en particular, parece no almacenar en caché cuando hay algo "poco común" sobre la configuración del encabezado de control de caché. ¿Alguien tiene un enlace para una buena prueba de esto? Odio hacerlo si ya se ha hecho ;-) – rmalayter

+0

La convención de notación que me perdí al leer la especificación fue que 1 # cache-directive significa una lista separada por comas de una o más directivas de caché. Por lo tanto, para delimitarla, consulte "#rule" en [convenciones de notación] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html) –

5

Estaba teniendo el mismo problema en diferentes configuraciones. Lo que funcionó para mí es cambiar el orden de dos líneas que establecen los encabezados y colocar la configuración del encabezado justo después del paréntesis de apertura del "servidor". Esto establecerá las cabeceras de todos los objetos tal vez, pero tal vez trabajará en ti "if" demasiado:


server { 
    expires  31d; 
    add_header Cache-Control public; 

    server_name example.com 
    ... 
} 

 

Parece que add_header envía cabecera antes de que expire directiva para tener tiempo para cambiarlo.

+0

No es exactamente la respuesta a la pregunta pero es muy relevante, IMO. –

+0

También no w ork más '' ' Cache-Control: max-age = 3600 \ n Cache-Control:, debe revalidar-privada, delegación revalidate, max-age = 3600''' config dice:' '' expira 1 h; \ n add_header Cache-Control "privado, debe revalidar, proxy-revalidar, max-age = 3600"; '' '(perdón por el formateo) –

Cuestiones relacionadas