A vulnerability scanner having to implement hairy heuristics to decide what's a vuln and what's a common false positive is literally its whole job.
A vulnerability scanner having to implement hairy heuristics to decide what's a vuln and what's a common false positive is literally its whole job.
It's silly to pretend that the use of a 404 in this type of circumstance is either clearcut in the standards or ubiquitous in practice.
The standards seem pretty clear to me.
I would point out that technically, the path portion of the HN URI does indeed point to a valid endpoint, it is the query portion of the URI (usually not used by the server to do any routing) that points to a non-existent resource.
Still, HN is wrong here and should be returning a 404 status.
To be fair, it's not about some rando on a blog post. The HTTP response codes and their semantics are in the RFCs. And while it's true the RFCs say SHOULD and not MUST, there are also now ~30 decades of experience and expectation that a non-existent resource is more likely a 404 not 200.
Sure a server can always do what it likes but can't expect it to play well with the outside world if it goes against both convention and documentation.