--maxage option not working?

[mustafa0x]

I have the following in package.json:

"start:dev": "sirv public --single --dev --host 0 --port 8080 -m 0"

However, the response headers lack cache-control. Is this a bug or did I misunderstand the usage of -m/--maxage?

On a related note, wouldn't it make sense to always pass a no cache header in dev mode?

[lukeed]

Hey, thanks!

So I do a sorta similar thing for --dev mode: It skips that maxAge / Cache-Control option entirely, which would effectively operate the same as a private Cache-Control directive.

Relevant section: https://github.com/lukeed/sirv/blob/master/packages/sirv/index.js#L79-L98
Notice that the opts.maxAge check happens after dev mode has been executed.

This is also true on the current @next release.

[mustafa0x]

Is there a way to explicit send Cache-control: no-store for dev mode (or even maxage=0)? Currently, I'm forced to use Disable cache in dev tools to make sure I always get a fresh response.

(Just now Dev tools was caching the sourcemaps of my bundles.)

[lukeed]

Not currently, through the CLI. If you were using sirv programmatically, you'd do that within a blanket setHeaders option.

What would you suggest? A new flag, or baking it into --dev? My hesitation is that some will still want to send CC headers while in dev mode, since "dev" just signifies that files are always sent from the filesystem & not an in-memory cache. And max-age=0 is not really the same as private/no-store.

[mustafa0x]

I feel that a no-store CC header should be default with --dev. As we all know, when we're developing we always want a fresh response. This is especially important where you can't force a refresh of the changes, e.g. when testing the app on the phone. This happened to me, and it was a bit frustrating. I was forced to add a cache-busting query string.

There do exist a few rare exceptions however, so perhaps that default can be overridden by passing maxage in or another option.

[lukeed]

Sounds good, will do 👍 Should it be private, too?

[mustafa0x]

Thanks!

As in Cache-Control: private? I think Cache-Control: no-store suffices.

public

• Indicates that the response may be cached by any cache, even if the response would normally be non-cacheable (e.g. if the response does not contain a max-age directive or the Expires header).

private

• Indicates that the response is intended for a single user and must not be stored by a shared cache. A private cache may store the response.

no-cache

• Forces caches to submit the request to the origin server for validation before releasing a cached copy.

no-store

• The cache should not store anything about the client request or server response.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

[lukeed]

Great, agreed

Do you mind if I put this into next only? That's close to being released so I'd prefer to have less commit-friction between the two branches

[mustafa0x]

I don't mind at all — whatever works best for you. Thanks!

…

On Thu, Oct 17, 2019, 12:12 AM Luke Edwards ***@***.***> wrote: Great, agreed Do you mind if I put this into next only? That's close to being released so I'd prefer to have less commit-friction between the two branches — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#45?email_source=notifications&email_token=AALHUTQXOVCGS2ASX7LNJX3QO57STA5CNFSM4JBHURKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBN6NQY#issuecomment-542893763>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALHUTWWS3C3J2BJC5UWBF3QO57STANCNFSM4JBHURKA> .

[lukeed]

Available on the new next version for both packages:

• sirv-cli@1.0.0-next.1
• sirv@1.0.0-next.1

npm install sirv-cli@next

Thanks!

[mustafa0x]

🎉