helmetjs / nocache Goto Github PK

My typescript project imports nocache like this.
import * as nocache from "nocache";

This worked fine until I upgraded the dependency to the version 3.0.2. I got the following error now:

error TS2497: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.

It is a typescript project with tsconfig.json like this:

...
    "compilerOptions": {
        "noImplicitAny": true,
        "target": "ES2020",
        "module": "commonjs",
        "watch": false,
        "sourceMap": true,
        "strict": true,
        "useUnknownInCatchVariables": false
    },
...

In RFC defined that no-store just specifies don't store a response in any cache and others in current implementations seems conflicted.

Why no just set only no-store in Cache-Control ?

See the Helmet-wide TypeScript project.

It has come to my attention that the Pragma header is no longer recommended as per the latest web standards and may already have been removed, be in the process of being dropped, or only kept for compatibility purposes. For more information: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma

The Pragma header was initially used to provide backward compatibility with HTTP/1.0 caches. However, with the widespread adoption of HTTP/1.1 and the introduction of cache-control directives, the Pragma header has become obsolete. The cache-control directives such as "no-cache" and "no-store" are now the standard mechanisms for controlling caching behavior.

I think in order to align with the latest web standards and best practices by removing the usage of the Pragma header from the library.

Please let me know about your opinions? I am happy to make a PR :)

Tasks:

• remove depd
• remove noEtag from source
• remove noEtag tests
• remove any options parsing; it's the only option
• make sure the README doesn't say anything about noEtag
• update the master changelog in helmetjs/helmet

Minor; I'll take care of this one.

Why private got removed? Also, shouldn't it be a breaking change?

Noticed it was missing!

The link to https://helmetjs.github.io/docs/nocache/ does not show nocache docs, but redirects to the Helmet doc overview page.

I just found out experimentally that app.use(nocache()) must come before app.use('/path/to/routes', routes) when exporting an app. Otherwise, the headers don't get added to all those routes.

Can you please just add 1 clause for future users?

Thanks

As discussed in #9, noEtag basically doesn't work. That's because many Express features set an ETag, even if it's been removed.

We need to:

1. When noEtag is set, show a deprecation warning. We should do this as we've done in Helmet before.
2. Remove noEtag from the readme, and any references to ETags.

Seems like the Cache-Control header should include private. Per RFC2616 14.9.1:

private: Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.

Caches like varnish will happily cache the current response, but would not if private were included.

Thoughts?

Reading the RFC for Cache-Control makes me think we should set max-age=0 in the directive. Is this correct?

There are cases where we simply want to set the nocache headers in a handler, depending on some condition. Using this as a middleware on those cases is not as convenient. We can get around it but it's ugly:

// If no cache-control headers are still defined, default to no-cache
if (res.get('cache-control')) {
    nocache()(null, res, () => {});
}

// some more code

..instead it would be cool to do:

// If no cache-control headers are still defined, default to no-cache
if (res.get('cache-control')) {
    nocache.setHeaders(res);
}

// some more code

(the name of the method can obviously be more appropriate).

Would you be willing to provide this functionality?

As described in the RFC Cache-Control: private disables caching by CDNs etc. So far so good. However, it actually allows non-shared caches - the browser has one - to cache the file: A private (non-shared) cache MAY cache the response.

Although, the code lists all the other "don't cache" values I would expect that some browsers get confused and decide to do caching.