2 min de leitura ·

Dúvida no cache cloudflare do TabNews

Olá,

Eu não entendo muito sobre esse assunto mas estou acompanhando as melhorias referente ao cache e o cuidado para não vazar dados com o compartilhamento de sessões com o cache

Como eu não entendo quase nada do assunto, bateu a curiosidade ao ver o cache-control definido no header do response da api sessions, junto com o set-cookie da sessão do usuário. Aparentemente é o próprio cloudflare que está definidndo dessa forma:cache-control: public, max-age=0, must-revalidate. Olhando assim, da pra presumir que a rota não vai ser cacheada e não teria problema de ter esse header no response, mas antes de procurar mais informações no google, eu perguntei para o ChatGPT se existia algum problema de ter esse header definido e ele respondeu isso:

O cabeçalho "Cache-Control" definido como "public" indica que as respostas podem ser armazenadas em cache por servidores intermediários, como os servidores de borda do Cloudflare. O valor "max-age=0" indica que o cache deve ser considerado obsoleto imediatamente após a sua validação, o que significa que o Cloudflare irá buscar uma nova versão da resposta do servidor de origem a cada solicitação. No entanto, se a resposta for considerada válida, ela pode ser armazenada em cache e compartilhada com outros usuários.

O que me deixou em dúvida foi o final:

No entanto, se a resposta for considerada válida, ela pode ser armazenada em cache e compartilhada com outros usuários.

Ficou meio confuso para mim, então resolvi perguntar aqui. Existe algum problema de manter esse header em rotas que não devem compartilhar informações privadas?

FelipeBarso

1 ano atrás

Olá @franceXopa, ~~é isso mesmo, a Cloudflare que está adicionando esse header.~~ [Edit 2] Na verdade tanto a Vercel como a Cloudflare adicionam esses cabeçalhos.

Não é um problema, já que a combinação max-age=0 com must-revalidate tem o mesmo efeito de no-store, mas é verdade que podemos (e devemos) ser mais explícitos e definir no-cache, no-store, must-revalidate para os endpoints sensíveis 👍

franceXopa

Autor

1 ano atrás

Por isso que tudo o que eu fazia no Cloudflare não funcionava, não sei porque nem passava pela minha cabeça que podia ser a Vercel adicionando essa configuração automaticamente

FelipeBarso

1 ano atrás

Editei minha resposta anterior para acrescentar que as duas CDNs modificam os cabeçalhos, tanto a Vercel quanto a Cloudflare.

Onde estamos definindo como no-cache, no-store, max-age=0, must-revalidate (aqui poderia ser apenas no-store 🤔) a Vercel mantém como definimos, mas a Cloudflare altera para public, max-age=0, must-revalidate.

Já onde definimos public, s-maxage=10, stale-while-revalidate
a Vercel modifica para public, max-age=0, must-revalidate e a Cloudflare modifica para public

franceXopa

Autor

1 ano atrás

Estou passando pela mesma situação

No meu caso, a Cloudflare não estava alterando imediatamente para public, mas, após algum tempo, a configuração definida no arquivo da página era substituída por public

Fui ver essa outra questão da vercel não definir o header que estava configurado no meu arquivo /api/v1/hello, pois acontece o mesmo que você mencionou

Fiz um pequeno teste editando o arquivo next.config.js e adicionei o header para a rota da api

{
   source: '/api/v1/hello',
   headers: [
      { key: 'Cache-Control', value: 'public, s-maxage=60, stale-while-revalidate' },
   ],
},

Depois dessa configuração, a rota /api/v1/hello ficou com a configuração certa (também testei com no-cache, no-store, max-age=0, must-revalidate)

Talvez esse não seja o melhor caminho, mas por enquanto não sei o que fazer

Não fiz nenhuma alteração no Cloudflare.