Why add Vary: origin, ACRM, ACRH in preflight response?

[mateusz834]

I don't understand these lines, I think that they are unnecessary.

cors/cors.go

Lines 268 to 270 in f9bce55

	headers.Add("Vary", "Origin")
	headers.Add("Vary", "Access-Control-Request-Method")
	headers.Add("Vary", "Access-Control-Request-Headers")

OPTIONS http method is as far as I am conserned not cacheable:
https://tools.ietf.org/html/rfc7231#section-4.3.7

"Responses to the OPTIONS method are not cacheable."

At first I thought Vary was used by preflight-cache, but https://stackoverflow.com/a/42849375/10256256 says that:

The CORS-preflight cache isn’t a general HTTP cache covered by requirements in the HTTP spec. It’s a special cache whose behavior is defined exclusively by the Fetch spec. And the Fetch spec doesn’t state any requirements—even indirectly—about the behavior of the CORS-preflight cache being affected at all by the Vary response header.
(...)
And because the spec doesn’t explicitly state if/how to use Vary when deciding whether to populate the CORS-preflight cache, then browsers must not use Vary when doing it.
If a browser did use Vary in its handling of the CORS-preflight cache, then that browser would be out of conformance with the spec requirements for the CORS-preflight cache.

So why these headers are added to preflight response?

[rs]

OPTIONS responses can be cached by intermediary caches (it’s often a good idea) and thus need this header to appropriately segment the cache.