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 Thu, 26 Feb 1998 05:13:38 GMT
On Wed, 25 Feb 1998, Marc Slemko wrote:

> On Wed, 25 Feb 1998, Dean Gaudet wrote:
> > This is the exact behaviour that I think Apache should have.  Right now I
> > consider us broken (well actually we are broken even if you take a more
> > limited view). 
> How do you make that fit with section 5.2 of 2068?
> Heck, how do you make anything fit with that?

This is what Roy and I were babbling about in the "absoluteURIs suck"

What part of 5.2 would this violate?  none of it.

   An origin server that does not allow resources to differ by the
   requested host MAY ignore the Host header field value. (But see
   section 19.5.1 for other requirements on Host support in HTTP/1.1.)

This essentially gives us permission to do it, although one of the glaring
omissions regarding absoluteURI and Host: is that the host from the
absoluteURI should be treated just like a Host: header.  5.2 gives origin
servers complete control over what they consider to be their hostname(s).

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.

A NameVirtualHost address is defined to serve all requests which are
not otherwise matched from the first vhost in the list.  We get this
right for the Host: header, but not for absoluteURIs.

These two are inconsistancies that make Apache not forward compatible
with future HTTP/1.x protocols.  Future protocols which will require
clients to send absoluteURI on all requests... and suddenly folks'
vhosts behaviour will change.  I want to fix this in 1.3b6.

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.


View raw message