Conversation
So that plugins (like usageLicensing) can set it to something else.
server/http.ts
Outdated
|
|
||
| response.headers.set('Server', 'Harper'); | ||
| if (!response.headers.has('Server')) { | ||
| response.headers.set('Server', 'Harper'); |
There was a problem hiding this comment.
We should not be setting a Server header. It's a security liability, adds unnecessary bytes to responses, and provides little to no value. Is this absolutely necessary?
There was a problem hiding this comment.
Generally the security liability is proportionate to the amount of detail provided about version (and the ability to detect known vulnerable versions). We aren't sending versions, so that concern is greatly mitigated.
I think the main benefit/purpose is probably advertising/awareness. Seeing our name in HTTP communication could slightly increase awareness of our product. Also note that we do also change this header to report unlicensed usage of Harper, which is intended to a small deterrent to using it for production use without a license: https://github.com/HarperFast/harperdb/blob/main/server/http.ts#L277
And I assume that's where Wes is going with this, since he is working on licensing.
However, I am certainly open to removing the header for the reasons you stated. Or at least not sending the header except when we want to report lack of licensing, which makes this code simpler; we just don't set it, and harper-pro can set it when it needs to.
There was a problem hiding this comment.
I would venture to guess that 99.99% of entities interested in the Server header are bots looking for servers to exploit. The license, or lackthereof, can be conveyed with an unassuming X-License header.
There was a problem hiding this comment.
And I assume that's where Wes is going with this, since he is working on licensing.
Yep 👍🏻
cap10morgan
changed the title
3 participants
So that plugins (like usageLicensing) can set it to something else.