Serverless-next.js: cache settings incorrect for dynamic app

[nodabladam]

_next/* behavior should use origin headers public, max-age=31536000, immutable
static/* behavior should use origin headers public, max-age=31536000, immutable
public/* behavior should use origin headers public, max-age=31536000, immutable

api/* behavior is set to custom cache headers with min, max, default TTL set to 5. I believe this needs to be set to origin headers. It is critical not to force api caching as these routes are used for stuff like login/logout.

Default (*) should be whatever next.js does for dynamic pages which I think is "cache-control: no-cache"? Without any cache-control wont browser cache?

[barrysteyn]

Is this how next does things? If so, can you point me to the code and I I will change things to mimic this.

This projects aims to mimic exactly how next does things, and so if this is not currently in Next, then I don't think we should do this by default here. Note the emphasis on default - there is always scope for exposing a setting that can allow for overriding things.

[nodabladam]

Sounds good. A combination of some changes to mimic current next and some documentation on how to override things would be great. I am not a Next.js headers expert so I appreciate you factoring in your likely more experience at what is best here for the community as a whole.

Basically when I roll my app out using serverless-next my users can't logout. I believe it must be due to cloudfront caching cookie headers on a prior response being reserved.

Updated ticket based on your feedback:

`_next/* behavior - I believe this is where Next.js sets immutable on their internal css and js:
https://github.com/zeit/next.js/blob/354de28422631bf2184a5e1faa4b7ab9ef15ea03/packages/next/next-server/server/next-server.ts#L239

static & public - It seems like Next.js leaves this to the user and people are using custom server for it: https://github.com/zeit/next.js/issues/1791
Something like this would probably be the equivalent: https://geeks.uniplaces.com/cache-control-with-lambda-edge-95645b3aa4f0
Can you document how a Next.js user that wants static & public to be immutable get the same behavior with serverless-next.js? If I attach my own lamdba to cloudfront it seems to gets replaced with the next serverless-next deploy.

api/* - I believe changing serverless-next.js to original headers rather than override with minimum 5/5/5 caching is the safest out of the box. I think it is unlikely 5 seconds is ever going to be practical....I think most people will either want 0 or larger values by default. This issue may be mitigated with documentation clearly calling out users of serverless-next need to set their own api headers if they don't want defaut 5/5/5. How can people get their own custom settings?

Default (*) behavior - like /api, it seems like serverless-next is doing Object Caching - "customize" default 5.

It seems like Next.js doesn't use cache-control for dynamic html pages so defaults apply. I worry it is unacceptable for cloudfront to be default caching dynamic apps serving private data and I suspect it should be changed to default 0 or origin headers for safety.

[danielcondemarin]

Sounds good. A combination of some changes to mimic current next and some documentation on how to override things would be great. I am not a Next.js headers expert so I appreciate you factoring in your likely more experience at what is best here for the community as a whole.

Basically when I roll my app out using serverless-next my users can't logout. I believe it must be due to cloudfront caching cookie headers on a prior response being reserved.

Updated ticket based on your feedback:

`_next/* behavior - I believe this is where Next.js sets immutable on their internal css and js:
https://github.com/zeit/next.js/blob/354de28422631bf2184a5e1faa4b7ab9ef15ea03/packages/next/next-server/server/next-server.ts#L239

static & public - It seems like Next.js leaves this to the user and people are using custom server for it: zeit/next.js#1791
Something like this would probably be the equivalent: https://geeks.uniplaces.com/cache-control-with-lambda-edge-95645b3aa4f0
Can you document how a Next.js user that wants static & public to be immutable get the same behavior with serverless-next.js? If I attach my own lamdba to cloudfront it seems to gets replaced with the next serverless-next deploy.

api/* - I believe changing serverless-next.js to original headers rather than override with minimum 5/5/5 caching is the safest out of the box. I think it is unlikely 5 seconds is ever going to be practical....I think most people will either want 0 or larger values by default. This issue may be mitigated with documentation clearly calling out users of serverless-next need to set their own api headers if they don't want defaut 5/5/5. How can people get their own custom settings?

Default (*) behavior - like /api, it seems like serverless-next is doing Object Caching - "customize" default 5.

It seems like Next.js doesn't use cache-control for dynamic html pages so defaults apply. I worry it is unacceptable for cloudfront to be default caching dynamic apps serving private data and I suspect it should be changed to default 0 or origin headers for safety.

@nodabladam Thanks for the great detail.

• The _next/* behaviour we got it right already https://github.com/danielcondemarin/serverless-next.js/blob/0cc446c9f996b8773b2aa999da9c3a3f2bd9a996/packages/serverless-nextjs-component/serverless.js#L244

• static & public I agree it should be user configurable. Maybe users could pass a regex to match which files get the cache control header:

component: serverless-next.js
inputs:
  cache:
    regex: '*.(jpg|png)' # match images in the public or static folder
    value: "public, max-age=31536000"

The above is just an example of what it could look like, definitely not set in stone.

The 5 seconds default has to be changed to zero, that was a mistake that needs fixing 👍

[barrysteyn]

Technically, I don't think it is that difficult putting a regex on the static and public folders. However, Should we also allow a default cache setting (like "cache-control: no-cache") for every file?

[Enalmada]

The regex idea seems great. If it could support the header it could cover more cases:

inputs: 
   headers:
      header: "cache-control"
      regex: '*' 
      value: "public, max-age=31536000, immutable"

[danielcondemarin]

The regex idea seems great. If it could support the header it could cover more cases:

inputs: 
   headers:
      header: "cache-control"
      regex: '*' 
      value: "public, max-age=31536000, immutable"

Not sure we can set any header other than Cache-Control. Bear in mind this will happen at build time and added to the files in public/ or static/.

What other headers did you have in mind?

Also, there is an RFC in next https://github.com/zeit/next.js/issues/9081 which overlaps with this.

[Enalmada]

No, I was just thinking aloud. All that matters to me is a way to get everything immutable.

[barrysteyn]

I can confirm that (for now), we can only set cache-control. Also, I believe AWS S3 has a fixed domain of headers to set (i.e. one cannot just set any headers). That being said, whatever header in that domain is to be set, it would require the AWS S3 component to be altered. Even though the changes are incredibly quick, the maintainers of the component take their time to merge (they even be actively ignoring the components???)

So I think we should restrict ourselves to setting cache header. @danielcondemarin we would probably want a separate function that would take a directory, regex, cache setting (since this seems like a common pattern):

const defaultCacheHeader = "cache-control: no-cache";
const uploadDirWithHeader = (directory, regex="", cacheHeader="") => {
   cacheHeader = cacheHeader ? defaultCacheHeader : cacheHeader
  // Examine files here and if matches regex, set cacheHeader, else defaultCacheHeader
}

[barrysteyn]

Hi Dan

Regarding this:

• static & public I agree it should be user configurable. Maybe users could pass a regex to match which files get the cache control header:

component: serverless-next.js
inputs:
  cache:
    regex: '*.(jpg|png)' # match images in the public or static folder
    value: "public, max-age=31536000"

The above is just an example of what it could look like, definitely not set in stone.

I believe that until the S3 component is updated, it will be very difficult to apply a cache setting to a regex pattern. However, why don't we allow caching for public and static (since static will be redundant soon, it can just be one option) that will apply cache options to all public/static files. Then when S3 component eventually allows merges, we can give it regex functionality and update this component as well?

[danielcondemarin]

Closing this. You can now cache SSR pages adding a CloudFront cache behaviour, see https://github.com/danielcondemarin/serverless-next.js#custom-cloudfront-configuration.

For the static / public directory caching see https://github.com/danielcondemarin/serverless-next.js#public-directory-caching