Closed stevan closed 7 years ago
Can you provide an example (or links to docs) for what Linkerd does?
From a strict read of RFC-7230, I'm inclined to say no:
If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1)
That's pretty clearly that a user request for http://foo/
must have Host: foo
as the corresponding header.
Can you do what you need either with the existing peer
option or via http proxy settings instead?
An example of what Linkerd is trying to do can be found here, which definitely seems like an abuse of the header. I will go bug them and see what they say. Thanks.
Yes, that seems like they ought to just use a custom header.
I don't think this is a unreasonable request (combined with an boolean flag), back in the days I used to telenet to a host using an IP address and send a custom Host header. override_host_header
=> boolean would probably be a better name.
I'd still like to know if it can be done another way -- e.g. use Linkerd as a proxy host and send a request with the bogus host as the URI.
So after some digging we've found that Linkerd's usage of Host
is just the default and can be easily configured away, so this is no longer needed. Thanks guys :)
We are wondering if you would be willing to make the error for the
Host
header optional? Here is the code in question, https://github.com/chansen/p5-http-tiny/blob/master/lib/HTTP/Tiny.pm#L792-L794Our use case involves using Linkerd, which uses the
Host
header in a somewhat overly friendly kind of way (but, technically legitimate way, in my opinion at least).Our proposal would be to simply add a boolean constructor parameter called something like
allow_host_header
and then add a check inside the conditional on this line https://github.com/chansen/p5-http-tiny/blob/master/lib/HTTP/Tiny.pm#L792 to throw the error appropriately.If you are okay with this I will happily prepare a patch.