Improve hint-no-disallowed-headers

[alrra]

Look over: https://www.fastly.com/blog/headers-we-dont-want, and see if we can add more unneeded headers to the list.

The code for this hint is under packages/hint-no-disallowed-headers/

[captainbrosset]

After reading that article and looking at the code from this hint, I think we could safely add the following headers into the list of disallowed headers:

• Expires
• Host
• P3P
• Pragma
• Via
• X-Frame-Options
• X-UA-Compatible

If I understand correctly, the hint also supports configuring ignored headers, so even if, by some chance, someone was using those outdated headers, they would be able to ignore the warnings.

The only thing I'm wondering about is: it's easy enough to add them to the disallowedHeaders array, but since the article goes to great length explaining what these headers are and why they're not necessary, I'm wondering if instead they should each have some specific logic with corresponding localized strings, so users can learn why they're getting warnings.

What do you think @antross ?

[antross]

@captainbrosset having more detailed messages on a per-header basis would be great! We can keep the general message for any headers we don't have something more to say about (or additional ones included via the webhint configuration that aren't part of the default set).

Also, there are a couple of related issues in this space:

• [Hint] Deprecated cache-related headers and directives #2730, which really just references Pragma as far as this hint is concerned so you've already got that covered.
• [Bug] Move obsolete headers in no-html-only-headers to no-disallowed-headers #2350, which was broken out from [Docs Bug] Header advice wrong #2342, suggesting we may want to move some of the now-obsolete headers from hint-no-html-only-headers here. We don't have to do that now, but I wanted to give you a heads-up. There was also a mention of whether X-Frame-Options should be allowed, but given the recommendation from the article to replace it with Content-Security-Policy I think we're good to keep it in the list.

[KittyGiraudel]

Taking the liberty to comment on this issue, especially regarding the Via HTTP header. More often that not, it appears that this header is added by proxies, which makes it difficult or impossible to fix. For instance, Google Cloud Load Balancing adds Via: 1.1 google to incoming requests and responses. Any CDN sitting behind GCLB, such as Sanity’s, will display this header.

The article linked in the original message from this issue also mentions this. Although it does say it’s most likely safe to remove (which I’m not arguing here), it also states that proxies have to set it up, and most people don’t have control over their proxy.

More debatable perhaps is Via, which is required (by RFC7230) to be added to the request by any proxy through which it passes to identify the proxy. This can be the proxy’s hostname, but is more likely to be a generic identifier like “vegur”, “varnish”, or “squid”. Removing (or not setting) this header on a request can cause proxy forwarding loops. However, interestingly it is also copied into the response on the way back to the browser, and here it's just informational and no browsers do anything with it, so it’s reasonably safe to get rid of it if you want to.

I was wondering if you’d be considering dropping the Via warning.