Re: SNI vs Host: and a trailing dot

> On 16 Mar 2016, at 11:17, Daniel Stenberg <daniel@haxx.se> wrote:
> 
> Following these specs, we should send different names in SNI vs Host when a trailing dot is used. I don't like that as I suspect HTTPS servers will use the SNI field to serve contents while HTTP servers can only use Host: header and thus this will make them act differently. I also suspect some servers won't like getting different names in there, but I don't have any proof of that.
> 
> Right now, only curl[*] seems to have been stripping the dot from the SNI name according to this wget bug report:
> https://savannah.gnu.org/bugs/?47408#discussion
> 
> Qt is about to fix it: https://bugreports.qt.io/browse/QTBUG-51821
> 
> And here's the Firefox bug for trailing dots in SNI fields: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120
> 
> ... but it looks like curl is also the only one[*] that strips the dot from the Host: header. So curl violates RFC 7230, and most of the others seem to violate RFC 6066, unless I'm mistaking.
> 
> I think it would benefit us all to get a common view on how to clear this up!

I’d like a good answer on this. Currently requests mishandles trailing dots in URLs (I think our users have spotted this though and simply don’t use them), and if I’m going to go to fix that bug I’d like to fix it in a way that has some consensus! (Rather than doing what most of us do in this situation, which is to shrug our shoulders and do what curl does.)

FWIW, our data point is that we leave the trailing dot on the authority in all cases: SNI, Host header, and TLS hostname validation (which is clearly wrong but fails closed so could be a lot worse).

Cory