[Docs Bug] "Unneeded HTTP headers" is not very descriptive.

[Malvoz]

https://github.com/webhintio/hint/blob/master/packages/hint-no-html-only-headers/README.md

While visiting the corresponding URL on the webhint website, the headline "Unneeded HTTP headers" gave me a feeling of urgency to start removing headers, lol.

[antross]

Good point, though I do like preserving something indicating the headers are unnecessary.

Granted with our recent changes in #2618 even the ID of the hint may be slightly out of alignment as a few other content types in addition to HTML are now involved, but I'll hold off recommending an ID change just yet as that should get more consistent once we break the CSP headers into a separate hint per #25.

Perhaps something closer to the ID like "HTML-only HTTP headers" would get the point across. Still slightly inaccurate in the short-term, but I can live with that.

[chrisgraham]

(My feedback was requested, so I'll chime in)

The concern is that a lot of people running scanning tools are not experienced engineers. I mean that in 3 senses:

1. They don't understand how an engineer makes design trade-offs
2. They don't really understand the technologies involved
3. They don't understand the evolving context that decisions are made in, with no single unchanging point of authority
   Or maybe people running scanning tools are engineers but they feel bad about themselves if they aren't able to get 100% in a tool. It's literally like failing a test to them.

Personally, I am lead developer of a CMS that novice users will deploy to manage their websites, and run these kinds of tools. So I am particularly sensitive to being the target of people thinking things are bugs, when really they are well-considered design decisions. "Microsoft knows better than you".

I don't have any problem with overly-zealous/false-positive errors in a tool though so long as these 3 principles are met:
a) There is legitimate (non-pedantic) reason for the error.
b) It is not possible to make the error more focused to avoid false-positives.
c) The situation is properly documented, so the user knows there is a trade-off involved from the 'official' source of the reported error.

[molant]

"Microsoft knows better than you"

Even though Microsoft contributes a lot of resources, this is an OpenJS Foundation project with an open governance. We really want to get feedback from all the community (not only browser vendors) to make sure we cover as much as possible and have in consideration cases like yours. So sincerely thank you for taking the time to write all of this comments.

they feel bad about themselves if they aren't able to get 100% in a tool

That's the main reason why we avoid given a score or anything similar 😞

Definitely agree with your points above. We've tried following a similar approach with the severity changes:

• Error - Will definitely not work as intended in at least one of the target browsers
• Warning - Minor impact or may not cause problems in practice (even if technically "wrong")
• Hint - Fine for now, but could cause problems in the future if something changes
• Information - Additional context or FYI, possibly to help with other parts of a feature

With the latest release the reports now have a warning level. We haven't updated the online scanner yet but when we do I believe we'll set the threshold to error.

I've created #3437 so users can easily find out what each level means and if they should fix it right away or not.