El modelo de expiración conviene usarlo siempre que sea posible. Cuando una response es cacheada con expiración, la cache guardará la response y la devolverá directamente sin que llegue a la aplicación, hasta que expire. Esto modelo se emplea con los headers Expires y Cache-Control.
Expiración con el headers Expires
Según la especificación HTTP: el campo header Expires indica la fecha/hora después de que la cual la response es considerada stale. El header Expires puede establecerse con el método Response setExpires(). Toma una instancia de DateTime como argumento:
$date = new DateTime();
$date->modify('+600 seconds');
$response->setExpires($date);El header HTTP resultante se mostrará como sigue:
Expires: Thu, 01 Mar 2011 16:00:00 GMTEl método setExpires() convierte automáticamente la fecha a la GMT timezone tal y como se indica en la especificación.
En versiones anteriores a HTTP 1.1 no era necesario que el servidor de origen enviara el header Date. Consecuentemente, la cache (del navegador por ejemplo) podría necesitar basarse en la hora local del reloj para evaluad el header Expires. Otra limitación del header Expires es que la especificación establece que "Los servidores HTTP/1.1 no deberían enviar fechas Expires de más de un año en adelante".
Expiración con el Cache-Control Header
Debido a las limitaciones del header Expires, la mayoría de las veces se debería utilizar el header Cache-Control en su lugar. Este header permite establecer varias directivas de cache. Para expiración existen dos: max-age y x-maxage. La primera se utiliza por todas las caches, mientras que la segunda sólo la tienen en cuenta las caches compartidas:
// Establece el número de segundos después de los cuales la response
// no debería considerarse fresh
$response->setMaxAge(600);
// Igual que la anterior pero sólo para caches compartidas
$response->setSharedMaxAge(600);El header Cache-Control tomaría el siguiente formato (podría tener directivas adicionales):
Cache-Control: max-age=600, s-maxage=600
