- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Sat, 10 May 97 17:06:11 EDT
- To: http-wg@cuckoo.hpl.hp.com
- Cc: dwm@xpasc.com, snowhare@netimages.com
"David W. Morris" <dwm@xpasc.com> wrote: > [...] > On Sat, 10 May 1997, Benjamin Franz wrote: > > [...] > > An attempt to chop FQDNs down to the host feels to me like the kind of > > protocal 'shortcut' (Shortcut: Noun; A path or course of action taken by > > lazy people that only takes twice as much time and effort as the original > > path or course of action would have taken.) that created the problem that > > Host: solves in the first place - ambiguous identification of multiple web > > servers sharing a single IP address. Why take a step *backwards* for the > > sake of people's lazyness in typing? > > Excuse me... who are we serving here? Users or server and DNS operators. A > major step backwards exists if we insist that a user type a FQDN and the > client magically know it is or is not a FQDN so the protocol can demand > that a host: field include a FQDN for the portion of content providers who > use virtual hosts. > > I'm not a DNS expert, but my understanding/recollection is that for www to > resolve, the DNS must be configured to allow such a resolution. If I'm > wrong, then fix the DNS configurations, demanding users be forced to type > a FQDN is giant step backward. I think Benjamin Franz has made an incorrect assumption. There is no "attempt to chop FQDNs down to the host". I thought the rule of thumb was to be that the Host header should contain the host/port portion of the URL exactly as it appears in the URL. Therefore, except when a user enters a URL by hand, the content provider typically controls what's in the URL and, therefore, what gets passed in Host. If an HTML page contains a URL with a FQDN, that's what would appear in the Host header. Dave Kristol
Received on Saturday, 10 May 1997 14:11:17 UTC