Re: [OFF TOPIC] more IIS tricks...

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

>An *ip only* vhost serves all requests that reach it.  You can send
>a request to www.arctic.org port 80, and say "Host: www.netscape.com"
>and it will happily serve www.arctic.org to you.  It damn well better:
>because I've told it to serve www.arctic.org to you.  But right now
>if you say "GET http://www.netscape.com/..."  what does Apache do?
>*A DNS LOOKUP*.  Denial of service.

We can fix that.

>Insert Dean's standard rant about how name vhosts are an inaccurate
>protocol.  Oh yeah, I meant to reply to Roy about this one.  Roy, even
>though I use www.chem.happy.edu vs. www.cs.happy.edu as an example
>my example works equally well with www.foobar.com and www.barfoo.com
>name-vhosted by an ISP -- if the folks at foobar.com put "http://www/"
>into their browser it won't work right.  This is why I think HTTP/1.1
>should contain a paragraph encouraging clients to send FQDNs.

It just doesn't matter.  If the folks at foobar.com put "http://www/"
into their browser, I don't give a rat's ass as to whether it will
work right, at random, or not at all.  There is absolutely no reason
for the protocol to unambiguously handle ambiguous requests, period.
The fact that an insignificant case such as this one won't always
give an "accurate" result does not change the fact that all significant
cases work just fine.

BTW, the URI specification already includes the paragraph you mention,
since this is a URI reference issue and not an HTTP decision.

....Roy

Re: [OFF TOPIC] more IIS tricks...

[Dean Gaudet <dg...@arctic.org>]

On Thu, 26 Feb 1998, Roy T. Fielding wrote:

> >An *ip only* vhost serves all requests that reach it.  You can send
> >a request to www.arctic.org port 80, and say "Host: www.netscape.com"
> >and it will happily serve www.arctic.org to you.  It damn well better:
> >because I've told it to serve www.arctic.org to you.  But right now
> >if you say "GET http://www.netscape.com/..."  what does Apache do?
> >*A DNS LOOKUP*.  Denial of service.
> 
> We can fix that.

Yes and I plan to.  If it's not a proxy server then no matter what host is
stuffed into the absoluteURI something will be served.  It will be treated
just like Host: is treated, which is how I read RFC2068... and it's how I
expect my servers to behave.  I want my servers serving hits regardless of
how lame a client is configured -- because I don't want to pay the waste
of support time to deal with users who are confused. 

> >Insert Dean's standard rant about how name vhosts are an inaccurate
> >protocol.  Oh yeah, I meant to reply to Roy about this one.  Roy, even
> >though I use www.chem.happy.edu vs. www.cs.happy.edu as an example
> >my example works equally well with www.foobar.com and www.barfoo.com
> >name-vhosted by an ISP -- if the folks at foobar.com put "http://www/"
> >into their browser it won't work right.  This is why I think HTTP/1.1
> >should contain a paragraph encouraging clients to send FQDNs.
> 
> It just doesn't matter.  If the folks at foobar.com put "http://www/"
> into their browser, I don't give a rat's ass as to whether it will
> work right, at random, or not at all.

You may not give a rat's ass, but you're also not an ISP using this
protocol.  You're not a tech support person at that ISP, and you're not
the naive end user who is dealing with a lame client.  I'm bothered by
this for support reasons mostly. 

I cringe when my coworkers refer to our internal webserver by its
unqualified name.  They've no idea why I'm cringing.  I'm probably the
only one there that uses the FQDN.  These aren't dumb users either,
they're just not aware what's going on behind the scenes.  If we ever use
authentication or cookies on this server... boy will they be annoyed at
how broken they are with unqualified names. 

> There is absolutely no reason
> for the protocol to unambiguously handle ambiguous requests, period.
> The fact that an insignificant case such as this one won't always
> give an "accurate" result does not change the fact that all significant
> cases work just fine.
>
> BTW, the URI specification already includes the paragraph you mention,
> since this is a URI reference issue and not an HTTP decision.

That's nice to know, thanks.  Now I can only hope microsoft does the right
thing eventually; since we'll be able to force netscape to do the right
thing shortly anyhow. 

Dean