SNI vs Host: and a trailing dot

Heya HTTP peeps!

Input "HTTPS://example.com./". A URI using a hostname with a trailing dot. How 
to behave?

1. RFC 6066 section 3 says the hostname in SNI string should be sent "without 
a trailing dot"

2. RFC 7230 secion 5.4 says about Host: "MUST send a field-value for Host that 
is identical to that authority component" - which then would include the 
trailing dot.

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!

Thoughts?

[*] = out of the ones I checked. I only checked a small selection of clients 
but the point is more that it isn't a general agreement.

-- 

  / daniel.haxx.se

Received on Wednesday, 16 March 2016 11:17:55 UTC