- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 17 Mar 2016 05:25:39 +0100
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Mar 17, 2016 at 12:15:35AM +0100, Daniel Stenberg wrote: > On Thu, 17 Mar 2016, Mark Nottingham wrote: > > >>I suspect HTTPS servers will use the SNI field to serve contents > > > >They shouldn't be doing that (if indeed they do); SNI is only for > >selecting the certificate, not anything to do with what happens inside > >HTTP. > > Right, I wrote that part too quick without thinking properly. Sorry. Thanks > for clearing that up! No, you were right to raise this point, because I spend a lot of time explaining people that HTTP routing has to be done on the Host header exclusively and that they must never use SNI for this. The only example I find to justify this is to say that older clients may not send SNI, but as you can guess this is a weak argument. Now with this trailing dot issue and the missing port that Xiaoyin mentionned, it's clear that SNI and Host may differ and that's a good argument. > I've since tested a bunch of random popular HTTPS sites by adding a dot to > the host name in the Host: header (while keeping it out of the SNI field) > and quite clearly there's a non-zero amount of servers that deliver > completely different headers/contents than if the header is sent without the > dot. I'm not surprized, it's very common to match an exact string on the server side. A lot of load-balancing configurations I'm seeing are even case-sensitive just because people don't know the host part is case-insensitive. Willy
Received on Thursday, 17 March 2016 04:26:08 UTC