- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 17 Jul 2025 17:40:12 +0200
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Lucas Pardue <lucas@lucaspardue.com>, HTTP Working Group <ietf-http-wg@w3.org>
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