Re: Handling multiple Host header fields in HTTP/2 and HTTP/3

On Thu, Jul 17, 2025 at 11:18:54AM +0100, Lucas Pardue wrote:
> Yes you read my mind a bit, there is deduplication after validation. I just
> can't seem to square the circle on whether to enforce the multiple Host
> check unilaterally across versions or not. Any time there is a mismatch
> like this is a risk a customer gets confused why something that worked one
> way with HTTP/1.1 suddenly didn't work the same if they change version.

It's always difficult. I used to reject multiple content-length headers
(I was one of those advocating for this long ago) until I met situations
where some layered applications put it twice. I've had a few other headers
met twice over time, each time a bogus home-made client or server. IMHO,
as long as the comma is not permitted in the header value, it should be
fine to deduplicate them (with strict checks) and fix the faulty message.

I think you're just in the same situation as me, when you're on an
intermediary, you sometimes hear "but it worked fine before we inserted
your stuff there". On this point we're extremely cautious, but I prefer
to fix non-ambiguous messages from time to time rather than seeing users
do horrors upfront to work around the problem and make it even worse.

IMHO it's among the parts where we should not change the spec (OK we've
relaxed content-length because it was not uncommon), and I think there
will always be a few MUST here and there that a few of us are forced to
arrange with when deploying in the field, and possibly to recheck once
in a while if still needed. Duplicate hosts are super rare for me but
cannot easily be fixed since server-side people rarely know how to
contact client owners...

Cheers,
Willy

Received on Thursday, 17 July 2025 15:40:21 UTC