https://bz.apache.org/bugzilla/show_bug.cgi?id=58007
--- Comment #12 from Fred Morris <[email protected]> --- Wow. Well, there's a lot more to this than I reckoned... for the most part this discussion is beyond me. I do have one comment: any final dot should be ignored for comparison purposes. > 3) server/vhost.c::fix_hostname() should stop stripping the trailing dot. www.example.com and www.example.com. are the same thing; at least they're supposed to be, at least that's consistent with the principle of least surprise. Actually, the former is supposed to be the latter. Because nobody really wants to go to www.example.com.ru. or www.example.com.example.com. Right? But that's what would potentially happen with a search list. The search list will not be applied to the second one, because it ends in dot. So: DNS says they're equivalent, but with a footnote regarding resolvers and search lists. Apache logs them differently (with %{Host}i so I presume this comes from the Host: header): without and with the dot. I don't know if the client should be sending them differently... However I expect them to refer to the same (virtual) host, I would be very surprised if they didn't. Servers which don't treat them the same are as far as I'm concerned broken. (Apache does treat them the same, which is to say if you set up a NameVirtualHost with separate logging, both the no dot (logging 200) and dot (logging 400) get directed to that VirtualHost, which is defined without the dot.) Now that I'm paying attention, I don't see any ServerName examples with the trailing dot in the Apache manual. I just looked through RFC 2616. I didn't find anything about the dot (somebody else should check, in case I missed it). The examples all show without the dot though. For the SNI header, the relevant specification says that the hostname should be sent without the dot and it's very specific and clear about that. On that basis we can conclude that Firefox is broken (and it's hardly the only broken client out there); but it is consistent between the SNI hostname and the Host: header. Now I want to offer a different example: jira and jira. (It's a better example for these purposes than mail and mail., although you can ask the guy who owns mail.com about the impact of search lists if you don't see the importance.) jira. (with the dot) isn't going to resolve anywhere.. unless I have a private vanity TLD of jira. But if I have example.com in my search list, the resolver library tacks it onto jira and attempts to resolve jira.example.com. What gets logged is jira without the dot; and apparently that's consistent with SNI because the page gets served. What do we expect the browser to send in this case? In spite of Firefox's (misguided IMO) attempts to manage its own DNS resolution I don't think we can expect clients to have visibility into what the resolver is doing, I think we just have to expect this; and consequently (and unfortunately) we can't expect the server to magically apply the same search list and come up with jira.example.com. But nonetheless jira and jira. should be the same vhost as far as the server is concerned. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
