Open vuori opened 2 months ago
This is just my personal view, not the ATS view or the community view.
My short answer is no.
Putting how ATS currently behaves aside, the RFC sounds like the lack of :authority
pseudo-header does not necessarily invalidate a request. With that said, I can't think of a case that an intermediary cannot construct :authority
pseudo-header where it can send Host
header. I'd say such a request is malformed.
However, if there are HTTP/2 implementations behaving like that and there are ATS users willing to accept such requests, I don't mind having a setting to allow using Host
instead of :authority
.
As of 10.0.0, ATS http2 request parser rejects requests without the
:authority
pseudo-header. However, haproxy's http2 client will in many situations send requests that have theHost
header but no:authority
. There is an issue open about this on haproxy side: https://github.com/haproxy/haproxy/issues/2592. The underlying standardization issue seems to be different wording regarding conversion of aHost
header into an:authority
header in RFC 7540 vs. 9113, where haproxy hews to 7540 re: preserving http/1.1 semantics as far as possible when converting requests between protocols.The haproxy issue is originally about Jetty, which apparently ended up adding support for
Host
as an alternative to:authority
. What's the ATS view on this? Would it be reasonable to acceptHost
in lieu of:authority
if the latter is missing?