Re: NUDGE: Our piece on Host: and URLs (Fwd)

On Sat, 10 May 1997, Benjamin Franz wrote:

> On Sat, 10 May 1997, David W. Morris wrote:
> > On Sat, 10 May 1997, Roy T. Fielding wrote:
> > > 
> > > Why?  There is currently no need for host to be an FQDN, for either
> > > the Host field-value or a full-URL.  Please explain.
> > 
> > I agree with Roy ... we recently had a new rehash of the question and
> > it was/is quite clear that is is unreasonable to expect a client to
> > fabricate a FQDN for the host field if it wasn't in the URL.  The whole
> > purpose of the Host: field is satisified if the field is simply filled in
> > with the host:port portion of the URL.  
> 
> How do you intend to distinguish 'www.nihongo.org' from
> 'www.netimages.com' on my server? They share the same IP address, the same
> host name, and are completely unrelated. If I type 'http://www' on my
> browser, I *WILL* connect (since I am inside the network) - but the server
> will and *can* have no idea which of 6 different servers I *meant* to
> access - a problem that will worsen with time. FQDNs are a sine qua non
> of using the Host: header.. 

How do you propose anything but a user select what www means in your
context?  Why is what the user gets when typing www any worse than having
a user agent always required to present an error message to the user
because a FQDN wasn't furnished.  How does the client even know using
stardard library calls that some name xxx.it isn't a fully qualified
domain name?

If you configure your DNSs that www is resolved ... the error message
should come from your servers not for EVERY user of EVERY site, for
example in your case nihongo and netimages would be reasonable for the 
the user to type and reasonable for your server to be configured to
understand in the host: header.

Furthermore, it is reasonable for there to be a proxy which understands
how to resolve some host value which the client can never resolve via the
DNS it can see.  In that case, the client is never given access to any
mechanism for rewriting the host name and proxies are not expected to
rewrite the host: header.


> 
> > There are many (orders of magnitude)  more cases where a client would find
> > it impossible to create a FQDN than the obscure configuration where a
> > client can use a partial name to locate the server BUT the server can't
> > use that partial name to properly identify a virtual document root.
> 
> Well - that 'obscure configuration' happens on *EVERY* shared-IP server we
> own when I am working on them from within our network. I would be
> facinated if you could invent a way not requiring FQDNs where this
> 'obscure configuration' *wouldn't* happen without requiring me to install
> *two* virtual servers for every server we have (with co-committent
> configuration synchronization maintainance problems) and still allow me to
> support the standard convention of naming web hosts 'www'.
> 
> 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.

Dave Morris

Received on Saturday, 10 May 1997 11:06:48 UTC