¿Es posible almacenar en caché los métodos POST en HTTP?
https://stackoverflow.com/questions/626057
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Con una semántica de almacenamiento en 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?
Solución
El RFC 2616 correspondiente en la sección 9.5 (POST) permite el almacenamiento en caché del < fuerte> respuesta a un mensaje POST, si usa los encabezados apropiados.
Las respuestas a este método no son cacheables, a menos que la respuesta incluye los campos de encabezado Cache-Control o Expires apropiados. Sin embargo, La respuesta 303 (ver Otro) puede usarse 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 una memoria caché debe invalidar la entidad correspondiente después de una solicitud POST .
Algunos métodos HTTP DEBEN causar una caché para invalidar una entidad. Esto es ya sea la entidad mencionada por el Solicitud-URI, o por la Ubicación o Encabezados de ubicación de contenido (si están presentes). Estos métodos son:
- PUT - DELETE - POST
No me queda claro cómo estas especificaciones pueden permitir un almacenamiento en caché significativo.
Otros consejos
Según RFC 2616 Sección 9.5:
" Las respuestas al método POST no son cacheable, A MENOS QUE la respuesta incluye control de caché apropiado o Expira los campos de encabezado. & Quot;
Entonces, SÍ, puede almacenar en caché la respuesta de la solicitud POST, pero solo si llega con los encabezados apropiados. En la mayoría de los casos, no desea almacenar en caché la respuesta. Pero en algunos casos, como si no estuviera guardando ningún dato en el servidor, es totalmente apropiado.
Tenga en cuenta que, sin embargo, muchos navegadores, incluido el actual Firefox 3.0.10, no almacenarán en caché la respuesta POST independientemente de los encabezados. IE se comporta más inteligentemente en este sentido.
Ahora, quiero aclarar algunas confusiones aquí con respecto al RFC 2616 S. 13.10. El método POST en un URI no invalida el recurso para el almacenamiento en caché de " como algunos han dicho aquí. Hace que una versión previamente almacenada en caché de ese URI sea obsoleta, incluso si sus encabezados de control de caché indicaban una actualización de mayor duración.
En general :
Básicamente, POST no es una operación idempotente . Así que 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 en sí mismo tiene la intención semántica de publicar algo en un recurso. La POST no se puede almacenar en caché porque si haces algo una vez contra dos veces contra tres veces, entonces estás alterando el recurso del servidor cada vez. Cada solicitud es importante y debe ser enviada al servidor.
El método PUT en sí mismo está semánticamente destinado a poner o crear un recurso. Es una operación idempotente, pero no se utilizará para el almacenamiento en caché porque podría haber ocurrido DELETE mientras tanto.
El método DELETE en sí mismo está semánticamente destinado a eliminar un recurso. Es una operación idempotente, pero no se utilizará para el almacenamiento en caché porque podría haber ocurrido un PUT mientras tanto.
Con respecto 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 asunto y cuerpo, pero se deben enviar los dos correos electrónicos.
Con respecto al almacenamiento en caché de proxy:
Un servidor proxy HTTP que reenvía su mensaje al servidor nunca almacenaría en caché nada más que 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 a través de la verificación de su caché. Pero, por supuesto, se puede enviar una solicitud POST a su aplicación o complemento y puede tener su propio caché que puede leer cuando los parámetros son los mismos.
Invalidar un recurso:
Comprobando HTTP 1.1 RFC 2616 S. 13.10 muestra que el método POST debería invalidar el recurso para el almacenamiento en caché.
Si almacena en caché una respuesta POST, debe ser en la dirección de la aplicación web. Esto es lo que se entiende por " 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 adecuados. & Quot;
Se puede asumir con seguridad que la aplicación, que sabe si los resultados de un POST son idempotentes o no, decide si adjunta o no los encabezados de control de caché necesarios y adecuados. Si los encabezados que sugieren que se permite el almacenamiento en caché están presentes, la aplicación le informa 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.
El seguimiento de los GET se puede servir desde el caché bajo esta suposición.
Una aplicación que no puede adjuntar los encabezados necesarios y correctos para diferenciar entre respuestas POST en caché y no en caché tiene la culpa de cualquier resultado de caché no válido.
Dicho esto, cada POST que llega al caché requiere validación usando encabezados condicionales. Esto es necesario para actualizar el contenido de la memoria caché para evitar que los resultados de una POST no se reflejen en las respuestas a las solicitudes hasta que caduque la vida útil del objeto.
Si es algo que realmente no cambia los datos en su sitio, debería ser una solicitud GET. Incluso si es un formulario, aún puede configurarlo como una solicitud de obtención. Si bien, como señalan otros, podría almacenar en caché los resultados de un POST, no tendría sentido semántico porque un POST, por definición, es un cambio de datos.
Mark Nottingham ha analizado cuándo es posible almacenar en caché la respuesta de un POST. Tenga en cuenta que las solicitudes posteriores que deseen aprovechar el almacenamiento en caché deben ser solicitudes GET o HEAD. Consulte también httpbis
Los POST no se ocupan de representaciones del estado identificado, 99 veces de cada 100. Sin embargo, hay un caso donde lo hace; cuando el servidor sale de su forma de decir que esta respuesta POST es una representación de su URI, estableciendo un encabezado de ubicación de contenido que sea igual a la solicitud URI. Cuando eso sucede, la respuesta POST es como una respuesta GET a la misma URI; Puede almacenarse en caché y reutilizarse, pero solo para el futuro. GET solicitudes.
Por supuesto que es posible. Si desea capturar las solicitudes POST enviadas a su servidor y almacenar en caché los datos enviados para volver a enviarlos más tarde, no se preocupe.
La parte difícil entra en relación con " estado " ;. ¿Cómo decide que los datos que desea enviar al usuario realmente deberían ser los mismos? ¿Qué pasa si sus cookies han cambiado? ¿Cambia eso los datos que desea enviar?
¿Qué tal si el usuario realizó una solicitud POST a su página de inicio y, desde la última vez que lo hizo, otro usuario le envió un mensaje (utilizando algún sistema dentro de su sitio)? Debería identificarlo como un cambio. of-state, 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.
Con Firefox 27.0 & amp; con httpfox, el 19 de mayo de 2014, vi una línea de esto: 00: 03: 58.777 0.488 657 (393) POST (Cache) text / html https://users.jackiszhp.info/ S4UP
Claramente, la respuesta de un método posterior se almacena en caché, y también está en https. ¡Increíble!
POST se utiliza en Ajax con estado. Devolver una respuesta en caché para una POST anula el canal de comunicación y los efectos secundarios de recibir un mensaje. Esto es muy, muy malo. También es un verdadero dolor rastrear. Muy recomendable en 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ó! & Quot; página atrás que fue cacheada la semana pasada. Otros casos más complejos del mundo real resultan en una hilaridad similar.
