Why have Origin and Referer headers when Referer has enough information?

Question

If the Referer header has the Origin in it anyway, what is the point of having both?

If the server receiving an HTTP request wants to know the Origin, it can just look at the domain in the Referer header.

I understand that the Referer header is not sent if it's an HTTPS to HTTP request (and many other scenarios), but why didn't they design it so that instead of removing it, it was still sent, but it only had the domain name (which the Origin header would have)?

Phytography

There are more scenarios when referrers are not sent - developer.mozilla.org/en-US/docs/Web/HTTP/Headers/… - and changing the behavior of an existing header is much riskier than adding a new one. – Gasolier

I'm not asking about why they don't change it, I'm asking "why didn't they design it..." in such a way to begin with. – Phytography

The referrer header was invented long before cross-domain JavaScript calls were a thing. Same reasons horses weren't designed with airbags. – Gasolier

Answer 1

Citing from here https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that

In order to preserve privacy, any browser request can decide to omit the Referer header. So it is probably best to only check the Origin header. (In case you want to allow for users to preserve their privacy)

The Origin header is null in some cases. Note that all of these requests are GET requests, which means they should not have any side effects.

Uwton