must - ¿Es posible almacenar en caché los métodos POST en HTTP?
cache-control html5 (9)
Con Firefox 27.0 y con httpfox, el 19 de mayo de 2014, vi una línea de esto: 00: 03: 58.777 0.488 657 (393) POST (Caché) text / html https://users.jackiszhp.info/S4UP
Claramente, la respuesta de un método de publicación está en caché, y también está en https. ¡Increíble!
Con semántica de caché muy simple: si los parámetros son los mismos (y la URL es la misma, por supuesto), entonces es un éxito. ¿Es eso posible? ¿Recomendado?
De acuerdo con RFC 2616 Sección 9.5:
"Las respuestas al método POST no se pueden almacenar en caché, A MENOS QUE la respuesta incluya campos de encabezado Cache-Control o Expires apropiados".
Por lo tanto, SÍ, puede almacenar en caché la respuesta de solicitud de POST, pero solo si llega con los encabezados adecuados. En la mayoría de los casos, no desea guardar en caché la respuesta. Pero en algunos casos, como si no está guardando datos en el servidor, es totalmente apropiado.
Tenga en cuenta que, sin embargo, muchos navegadores, incluido Firefox 3.0.10 actual, no almacenarán en caché la respuesta POST independientemente de los encabezados. IE se comporta de manera más inteligente a este respecto.
Ahora, quiero aclarar algo de confusión aquí con respecto a RFC 2616 S. 13.10. El método POST en un URI no "invalida el recurso para el almacenamiento en caché" como algunos han indicado aquí. Hace una versión previamente en caché de ese URI obsoleto, incluso si sus encabezados de control de caché indicaron frescura de mayor duración.
El correspondiente RFC 2616 en la sección 9.5 (POST) permite el almacenamiento en caché de la respuesta a un mensaje POST, si usa los encabezados apropiados.
Las respuestas a este método no se pueden almacenar en caché, a menos que la respuesta incluya los campos de encabezado Cache-Control o Expires apropiados. Sin embargo, la respuesta 303 (Ver Otro) se puede usar para dirigir al agente de usuario a recuperar un recurso almacenable en caché.
Tenga en cuenta que el mismo RFC establece explícitamente en la sección 13 (Almacenamiento en caché en HTTP) que un caché debe invalidar la entidad correspondiente después de una solicitud POST.
Algunos métodos HTTP DEBEN hacer que un caché invalide una entidad. Esta es la entidad a la que hace referencia el URI de solicitud o los encabezados de Ubicación o Ubicación de contenido (si están presentes). Estos métodos son:
- PUT - DELETE - POST
No tengo claro cómo estas especificaciones pueden permitir el almacenamiento en caché significativo.
Mark Nottingham ha analizado cuándo es posible almacenar en caché la respuesta de un POST. Tenga en cuenta que las solicitudes posteriores que desean aprovechar el almacenamiento en caché deben ser solicitudes GET o HEAD. Ver también httpbis
Los POST no tratan en representaciones del estado identificado, 99 veces de cada 100. Sin embargo, hay un caso en el que sí lo hace; cuando el servidor se desvive por decir que esta respuesta POST es una representación de su URI, estableciendo un encabezado Content-Location que es el mismo que el URI de solicitud. Cuando eso sucede, la respuesta POST es como una respuesta GET al mismo URI; se puede almacenar en caché y reutilizar, pero solo para futuras solicitudes GET.
POST se utiliza en Ajax con estado. Devolver una respuesta en caché para un POST derrota el canal de comunicación y los efectos secundarios de recibir un mensaje. Esto es muy, muy malo. También es un verdadero dolor localizarlo. Muy recomendado contra.
Un ejemplo trivial sería un mensaje que, como efecto secundario, paga su salario de $ 10,000 la semana actual. ¡NO QUIERES obtener el "OK, pasó"! página anterior que fue almacenada en caché la semana pasada. Otros casos más complejos del mundo real resultan en una hilaridad similar.
Por supuesto que es posible. Si desea capturar las solicitudes POST enviadas a su servidor, y almacenar en caché los datos enviados de regreso para volver a enviarlos más tarde, sin problemas.
La parte difícil entra en relación con el "estado". ¿Cómo decide que los datos que desea devolver al usuario realmente deberían ser los mismos? ¿Qué sucede si sus cookies han cambiado? ¿Eso cambia los datos que desea enviar?
¿Qué tal si el usuario hizo una solicitud POST a su página de inicio, y desde la última vez que lo hizo, otro usuario le envió un mensaje (usando algún sistema dentro de su sitio)? Tendría que identificarlo como un cambio de estado , y envíe la nueva versión de su página de inicio, con una notificación sobre el mensaje al usuario la próxima vez que cargue la página de inicio. Incluso si los parámetros POST son los mismos.
Si almacena en caché una respuesta POST, debe estar en la dirección de la aplicación web. Esto es lo que significa "Las respuestas a este método no son cacaotables, a menos que la respuesta incluya los campos de encabezado Cache-Control o Expires apropiados".
Se puede suponer con seguridad que la aplicación, que sabe si los resultados de un POST son idempotentes o no, decide si adjuntar o no los encabezados de control de caché necesarios y adecuados. Si hay encabezados que sugieren que el almacenamiento en caché está presente, la aplicación le indica que el POST es, en realidad, un super-GET; que el uso de POST solo fue necesario debido a la cantidad de datos innecesarios e irrelevantes (para el uso del URI como clave de caché) necesarios para realizar la operación idempotente.
Los siguientes GET se pueden servir desde el caché bajo esta suposición.
Una aplicación que no puede adjuntar los encabezados necesarios y correctos para diferenciar entre las respuestas POST que se pueden almacenar y las que no se pueden almacenar en caché tiene la culpa de los resultados de almacenamiento en caché no válidos.
Dicho esto, cada POST que llegue al caché requiere validación utilizando encabezados condicionales. Esto es necesario para actualizar el contenido del caché para evitar que los resultados de un POST no se reflejen en las respuestas a las solicitudes hasta que expire el tiempo de vida del objeto.
Si es algo que en realidad no cambia los datos en su sitio, debe ser una solicitud GET. Incluso si se trata de un formulario, puede configurarlo como una solicitud de obtención. Mientras que, como otros señalan, podría almacenar en caché los resultados de un POST, no tendría sentido semántico porque un POST por definición está cambiando los datos.
En general:
Básicamente POST no es una operación idempotente . Entonces no puedes usarlo para el almacenamiento en caché. GET debe ser una operación idempotente, por lo que se usa comúnmente para el almacenamiento en caché.
Consulte la sección 9.1 de HTTP 1.1 RFC 2616 S. 9.1 .
Aparte de la semántica del método GET:
El método POST mismo está semánticamente destinado a publicar algo en un recurso. POST no se puede almacenar en caché porque si hace algo una vez frente a dos veces frente a tres veces, entonces está alterando el recurso del servidor cada vez. Cada solicitud es importante y debe ser entregada al servidor.
El método PUT en sí está semánticamente destinado a poner o crear un recurso. Es una operación idempotente, pero no se usará para el almacenamiento en caché porque podría haber ocurrido un DELETE mientras tanto.
El método DELETE mismo está destinado semánticamente a eliminar un recurso. Es una operación idempotente, pero no se usará para el almacenamiento en caché porque podría haber ocurrido un PUT mientras tanto.
En cuanto al almacenamiento en caché del lado del cliente:
Un navegador web siempre reenviará su solicitud, incluso si tiene una respuesta de una operación POST anterior. Por ejemplo, puede enviar correos electrónicos con Gmail con un par de días de diferencia. Pueden ser el mismo sujeto y cuerpo, pero ambos correos electrónicos deben enviarse.
Con respecto al caché de proxy:
Un servidor HTTP proxy que reenvía su mensaje al servidor nunca almacenaría en caché nada excepto una solicitud GET o HEAD.
Con respecto al almacenamiento en caché del servidor:
Un servidor por defecto no manejaría automáticamente una solicitud POST al verificar su caché. Pero, por supuesto, se puede enviar una solicitud POST a su aplicación o complemento y puede tener su propia memoria caché desde la que lee cuando los parámetros son los mismos.
Invalidar un recurso:
Comprobando el HTTP 1.1 RFC 2616 S. 13.10 muestra que el método POST debe invalidar el recurso para el almacenamiento en caché.