Re: protocol question, Roy?

["Roy T. Fielding" <fi...@ebuilt.com>]

> Quick question.  I am testing some of my own stuff, and I have noticed
> that with Apache 2.0, if I request:
> 
> GET http://www.yahoo.com/ HTTP/1.0
> 
> with the server (obviously no proxy module, since it doesn't work), I get
> the same response as if I just asked for:
> 
> GET / HTTP/1.0
> 
> Is that correct?  Should we check the host in the request against the
> hostname of the server?

You could get the whole poop from Dean, but the basic reasoning is
that if the server is configured to be an origin server, then
how it interprets what it receives as the Request-URI is up
to it.  We would prefer to send a error of some kind, but that
would require us to look up (at config time) the entire list of
names for this server, both for the present and for any legacy
names for which we are serving as host.  That might have been
worthwhile doing, but at the time there were many user agents
and a few proxies that would put the wrong information in the
Host header field for some types of requests.  Likewise, it
makes the task of configuring clustered load-balanced web servers
difficult, and adds a string compare to every request.

I think it would be legitimate for 2.0 to include a config directive
that listed all of the host names that this server would allow,
and place those host names in a hash table for fast lookup,
but I haven't had the urge to do that yet.

....Roy

Re: protocol question, Roy?

[dean gaudet <dg...@arctic.org>]

On Fri, 26 Jan 2001 rbb@covalent.net wrote:

> Try this on any version of Apache:
>
> telnet localhost 8080
> GET http://www.yahoo.com/ HTTP/1.0
>
> This will get you the index of the current machine.

that is correct.  and you'll get the index of the "current machine" (i.e.
default server) if you do this as well:

GET / HTTP/1.0
Host: www.yahoo.com

there's no way in hell apache can know all the names which refer to the
server.  any client out there can be configured with any DNS view they
want.  there's no lookup apache can do to figure out what the client
meant.  (especially when you consider the client can be configured with a
different dns search path ... and the user may just refer to a host named
"fred" whose full name is "fred.wilma.com".)

i think there's more reasons for this, but i'm too lazy to search the
archives to find them all.

-dean

Re: protocol question, Roy?

[rb...@covalent.net]

> >> Should we check the host in the request against the hostname of the
> >> server?
> 
> RFC 2616, section 5.2:
> 
>    1. If Request-URI is an absoluteURI, the host is part of the
>      Request-URI. Any Host header field value in the request MUST be
>      ignored.
> 
> I believe (from memory of the last time I looked at the code) we
> implement that requirement, i.e. throw away the Host header and treat
> the hostname in the request URI as if it were the Host header.
> 
> So any checking of the request URI that we do happens as part of the
> virtual hosting code.

Try this on any version of Apache:

telnet localhost 8080
GET http://www.yahoo.com/ HTTP/1.0

This will get you the index of the current machine.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: protocol question, Roy?

[Tony Finch <do...@dotat.at>]

"Roy T. Fielding" <fi...@ebuilt.com> wrote:
>
>> Quick question.  I am testing some of my own stuff, and I have noticed
>> that with Apache 2.0, if I request:
>> 
>> GET http://www.yahoo.com/ HTTP/1.0
>> 
>> with the server (obviously no proxy module, since it doesn't work), I get
>> the same response as if I just asked for:
>> 
>> GET / HTTP/1.0
>> 
>> Is that correct?

RFC 2616, section 5.1.2:

   To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies.

[...]

   The most common form of Request-URI is that used to identify a
   resource on an origin server or gateway. In this case the absolute
   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
   the Request-URI, and the network location of the URI (authority) MUST
   be transmitted in a Host header field.

i.e. we correctly handle absoluteURI requests in origin-server mode,
even though correct clients don't make requests like that.

>> Should we check the host in the request against the hostname of the
>> server?

RFC 2616, section 5.2:

   1. If Request-URI is an absoluteURI, the host is part of the
     Request-URI. Any Host header field value in the request MUST be
     ignored.

I believe (from memory of the last time I looked at the code) we
implement that requirement, i.e. throw away the Host header and treat
the hostname in the request URI as if it were the Host header.

So any checking of the request URI that we do happens as part of the
virtual hosting code.

>We would prefer to send a error of some kind, but that would require
>us to look up (at config time) the entire list of names for this
>server, both for the present and for any legacy names for which we
>are serving as host.

Ugh.

>Likewise, it makes the task of configuring clustered load-balanced
>web servers difficult, and adds a string compare to every request.

The current name-based vhosting code requires O(number of vhosts)
string comparisons per request :-(

>I think it would be legitimate for 2.0 to include a config directive
>that listed all of the host names that this server would allow,

it's calles ServerAlias

>and place those host names in a hash table for fast lookup,
>but I haven't had the urge to do that yet.

Yes, that would be nice :-)

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
"There are flying saucers. There's no doubt they are
in our skies. They've been there for some time."