httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [OFF TOPIC] more IIS tricks...
Date Fri, 27 Feb 1998 02:41:00 GMT
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 port 80, and say "Host:"
> >and it will happily serve to you.  It damn well better:
> >because I've told it to serve to you.  But right now
> >if you say "GET"  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 vs. as an example
> >my example works equally well with and
> >name-vhosted by an ISP -- if the folks at 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 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. 


View raw message