The `sensitiveHeaders` HTTP2 symbol should be initialized via `Symbol.for` instead

[szmarczak]

Is your feature request related to a problem? Please describe.

node/lib/internal/http2/util.js

Line 35 in 6eec858

const kSensitiveHeaders = Symbol('nodejs.http2.sensitiveHeaders');

Currently to use the symbol we need to import it from the http2 module. A better solution would be to use Symbol.for like in the case of custom inspect symbol.

Describe the solution you'd like

-const kSensitiveHeaders = Symbol('nodejs.http2.sensitiveHeaders');
+const kSensitiveHeaders = Symbol.for('nodejs.http2.sensitiveHeaders');

Describe alternatives you've considered

None.

[Lxxyx]

In the documentation(https://github.com/nodejs/node/blob/master/doc/guides/using-symbols.md), there are references to how global Symbols are used.

Global symbols should be preferred when a developer-facing interface is needed to allow behavior customization, i.e., metaprogramming.

After trying to read the related Issue (#34091) and Pull Request(#34145).

I think that sensitiveHeaders is a feature that developers are using in the http2 module, not a developer-facing interface, and naming it nodejs.http2.sensitiveHeaders may be a mistake.

Details still need to be explained by @addaleax , if this is a mistake, I will file a Pull Request to fix it.

[szmarczak]

Global symbols should be preferred when a developer-facing interface is needed to allow behavior customization, i.e., metaprogramming.

That's exactly the case here. If you declare the symbol in your headers object then the headers in that array won't be compressed. It's custom behavior, isn't it?

I think that sensitiveHeaders is a feature that developers are using in the http2 module, not a developer-facing interface

Following your thinking, let's revert nodejs.util.promisify.custom and nodejs.util.inspect.custom, because developers are using it in the util module.

A module is an interface. API stands for Application Programming Interface.