it-swarm-pt.tech

É possível armazenar em cache os métodos POST no HTTP?

Com semântica de cache muito simples: se os parâmetros forem os mesmos (e a URL for a mesma, é claro), será um sucesso. Isso é possível? Recomendado?

141
flybywire

O correspondente RFC 2616 na seção 9.5 (POST) permite o armazenamento em cache da resposta para um POST mensagem, se você usar os cabeçalhos apropriados.

As respostas a esse método não podem ser armazenadas em cache, a menos que a resposta inclua os campos de cabeçalho Cache-Control ou Expir apropriados. No entanto, a resposta 303 (Consulte Outro) pode ser usada para direcionar o agente do usuário para recuperar um recurso armazenável em cache.

Observe que a mesma RFC afirma explicitamente na seção 13 (Armazenamento em cache em HTTP) que um cache deve invalidar a entidade correspondente após uma solicitação POST .

Alguns métodos HTTP devem fazer com que um cache invalide uma entidade. Essa é a entidade referida pelo Request-URI ou pelos cabeçalhos Location ou Content-Location (se presentes). Esses métodos são:

  - PUT
  - DELETE
  - POST

Não está claro para mim como essas especificações podem permitir um cache significativo.

91
Diomidis Spinellis

De acordo com a Seção 9.5 da RFC 2616:

"As respostas ao método POST não são armazenáveis ​​em cache, a menos que a resposta inclua campos apropriados de controle de cache ou expira no cabeçalho."

Portanto, SIM, você pode armazenar em cache POST solicitação de resposta, mas somente se ela chegar com os cabeçalhos apropriados. Na maioria dos casos, você não deseja armazenar em cache a resposta. Mas, em alguns casos - como se você não estiver salvando nenhum dado no servidor - é totalmente apropriado.

Observe que muitos navegadores, incluindo o Firefox 3.0.10 atual, não armazenam em cache a resposta POST independentemente dos cabeçalhos. IE comporta-se com mais inteligência a esse respeito.

Agora, quero esclarecer algumas confusões aqui sobre a RFC 2616 S. 13.10. O método POST em um URI não "invalida o recurso para armazenamento em cache", como alguns declararam aqui. Ele faz uma versão anteriormente armazenada em cache desse URI obsoleto, mesmo que seus cabeçalhos de controle de cache indiquem frescor de duração mais longa.

63
reBoot

Total:

Basicamente POST não é uma operação idempotente . Então você não pode usá-lo para o cache. GET deve ser uma operação idempotente, por isso é comumente usado para armazenamento em cache.

Por favor, veja a seção 9.1 do HTTP 1.1 RFC 2616 S. 9.1 .

Diferente da semântica do método GET:

O método POST é semanticamente destinado a postar algo em um recurso. POST não pode ser armazenado em cache porque se você fizer algo uma vez vs duas vezes vs três vezes, então você está alterando o recurso do servidor a cada vez. Cada pedido é importante e deve ser entregue ao servidor.

O método PUT em si é semanticamente destinado a colocar ou criar um recurso. É uma operação idempotente, mas não será usada para armazenamento em cache porque um DELETE poderia ter ocorrido nesse meio tempo.

O método DELETE em si é semanticamente destinado a excluir um recurso. É uma operação idempotente, mas não será usada para armazenamento em cache porque um PUT poderia ter ocorrido nesse meio tempo.

Em relação ao cache do lado do cliente:

Um navegador da Web sempre encaminhará sua solicitação mesmo que tenha uma resposta de uma operação anterior POST. Por exemplo, você pode enviar e-mails com o gmail com alguns dias de intervalo. Eles podem ser o mesmo assunto e corpo, mas ambos os e-mails devem ser enviados.

Quanto ao cache de proxy:

Um servidor HTTP de proxy que encaminha sua mensagem para o servidor nunca armazenaria nada em cache, exceto uma solicitação GET ou HEAD.

Em relação ao cache do servidor:

Um servidor por padrão não manipulará automaticamente uma solicitação POSTvia verificação de seu cache. Mas é claro que uma solicitação POST pode ser enviada para seu aplicativo ou suplemento e você pode ter seu próprio cache que você leu quando os parâmetros são os mesmos.

Invalidando um recurso:

Verificar o HTTP 1.1 RFC 2616 S. 13.1 mostra que o método POST deve invalidar o recurso para armazenamento em cache.

31
Brian R. Bondy

Se você armazenar em cache uma resposta POST, ela deverá estar na direção do aplicativo da web. É isso que significa "As respostas a esse método não podem ser alteradas, a menos que a resposta inclua os campos de cabeçalho Controle de cache ou Expira apropriados".

Pode-se seguramente assumir que o aplicativo, que sabe se os resultados de um POST são ou não idempotentes, decide se deve ou não anexar os cabeçalhos de controle de cache necessários e apropriados. Se os cabeçalhos que sugerem que o cache é permitido estão presentes, o aplicativo informa que o POST é, na verdade, um super-GET; que o uso de POST só era necessário devido à quantidade de dados desnecessários e irrelevantes (para o uso do URI como chave de cache) necessários para executar a operação idempotente.

Os seguintes GETs podem ser servidos do cache sob essa suposição.

Um aplicativo que falha ao anexar os cabeçalhos necessários e corretos para diferenciar entre respostas POST armazenadas e não armazenáveis ​​é o culpado por quaisquer resultados de armazenamento em cache inválidos.

Dito isso, cada POST que atinge o cache requer validação usando cabeçalhos condicionais. Isso é necessário para atualizar o conteúdo do cache para evitar que os resultados de um POST não sejam refletidos nas respostas às solicitações até que a vida útil do objeto expire.

6
JohnS

Se algo que realmente não altera os dados do seu site, deve ser uma solicitação GET. Mesmo que seja um formulário, você ainda pode defini-lo como uma solicitação de obtenção. Enquanto, como outros apontam, você pode armazenar em cache os resultados de um POST, não faria sentido semântico porque um POST por definição está alterando os dados.

4
Kibbee

Mark Nottingham analisou quando é possível armazenar em cache a resposta de um POST. Observe que os pedidos subsequentes que desejam tirar proveito do cache devem ser pedidos GET ou HEAD. Veja também httpbis

Os POSTs não lidam com representações do estado identificado, 99 vezes em 100. No entanto, há um caso em que isso acontece; quando o servidor faz o possível para dizer que essa resposta POST é uma representação de seu URI, configurando um cabeçalho de local do conteúdo igual ao URI da solicitação. Quando isso acontece, a resposta POST é como uma resposta GET para o mesmo URI; ele pode ser armazenado em cache e reutilizado - mas apenas para solicitações GET futuras.

https://www.mnot.net/blog/2012/09/24/caching_POST .

2
dschulten

Claro que é possível. Se você deseja capturar POST solicitações enviadas ao seu servidor e armazenar em cache os dados enviados de volta para serem reenviados mais tarde - sem problemas.

A parte complicada vem em relação ao "estado". Como você decide que os dados que você deseja enviar de volta ao usuário devem ser os mesmos? E se seus cookies tiverem mudado - isso muda os dados que você quer enviar de volta?

Que tal se o usuário fez uma solicitação POST para sua página inicial e, desde a última vez em que fez isso, outro usuário enviou uma mensagem a ele (usando algum sistema em seu site). Você precisaria identificá-la como uma mudança de estado e envie a nova versão da sua página inicial, com uma notificação sobre a mensagem para o usuário na próxima vez que ele carregar a página inicial. Mesmo se os parâmetros POST forem os mesmos.

1
Shalom Craimer