Re: SNI vs Host: and a trailing dot

Hi Daniel,

My opinion is let them handle the trailing dot differently, since there is another difference between them: SNI doesn’t contain TCP port number, but Host header optionally includes the port number (e.g. Host: www.example.com:8080).

Best,
Xiaoyin

From: Daniel Stenberg<mailto:daniel@haxx.se>
Sent: Wednesday, March 16, 2016 7:23 PM
To: HTTP Working Group<mailto:ietf-http-wg@w3.org>
Subject: 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