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 👍
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
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
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.