Is it necessary to force `no-cache` for getServerSideProps?

[nikshenoy]

https://github.com/netlify/next-on-netlify/blob/a73045f878b47f7fac8d70ceafd7e0ca39759d15/lib/templates/netlifyFunction.js#L29

It seems like the current code is forcing no-cache to be set on Netlify function calls (including getServerSideProps). I think this makes sense in a lot of cases, however we just had a use case where it would be safe to cache the results of that server-side execution for some period of time and we wanted to express that by setting the Cache-Control setting in the getServerSideProps method. This seems to be problematic because next-on-netlify adds an additional no-cache header which conflicts with ours. Is this something that could be conditional on an existence check for the header?

[lindsaylevine]

hey @nikshenoy ! thanks for opening this :) apologies our override is affecting a use case of yours :/. happy to provide some clarity and see if we can find a resolution.

the default cache control set by next.js has negative side effects on netlify. the main problem here would be that next.js always sets the cache control and we, on the next-on-netlify side, wouldn't be able to determine if the header is a custom one set by you/the user or the framework default.

a few options at the moment:

1. patch NoN for your project to exclude this line
2. open a PR/issue to Next.js to allow configuring the default cache control to be empty (this would enable us to remove this line)
3. if this is for a page using getServerSideProps, you could possibly override our override (lol) in a custom _headers file or in your netlify.toml for the /.netlify/functions/next_my_ssr_page path? headers docs - not 100% sure that'd actually work though

let me know if you have any questions! in the longer term, we're working across the entire platform to resolve some of the negative side effects i mentioned earlier with certain caching strategies/headers.

[nikshenoy]

hey @lindsaylevine, I think the thing that makes sense is to make Next.js fix this so that we can override. The other thought I had, since Cache-Control is flexible and will ignore unknown directives, is to add a special directive if we're overriding (like non-override or some such) and then the NoN code would know not to add that header.

[lindsaylevine]

@nikshenoy yeah, i hear you. are you going to open an issue to next.js if you haven't already? would be interested in tracking that here!