To: new-httpd@hyperreal.com
Subject: Re: this host crap 
In-reply-to: Your message of "Wed, 24 Apr 1996 13:37:31 PDT."
             <Pine.SGI.3.91.960424125836.579a-100000@fully.organic.com>
Date: Fri, 26 Apr 1996 16:34:12 -0700
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-ID: <9604261634.aa09983@paris.ics.uci.edu>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

shoot me now, please ...

> HYPERREAL.COM
> WWW.APACHE.ORG
>   (okay, not that bizarre, but a reminder that we need to account for 
>   capitalization)

Yep.

> bong.com:80
> hyperreal.com:80
> taz.hyperreal.com:80
>   (a reminder that we need to deal with port #'s - I'd prefer to in this 
>   case sent back a 302 Location: (or is it 303?) removing the redundant 
>   :80 URL)

Yep.

> vrml.wired.com.
> www.apache.org.
> www.hyperreal.com.
> 
>   (a reminder that it looks like we'll have to handle ending-periods too)

Yep.

> Truely fucked up:
> 
> fgw
>    (sent by "NCSA_Mosaic/2.7b3 (X11;meson 4_52 mips)" and 
>    "NCSA_Mosaic/2.7b3 (X11;krypton 4_52 mips)" when accessing 
>    ecstasy.org, all coming from relay4.oleane.net

Well, it's a beta ...

> hyperreal.com:
> 
>    (is this legal?)

Yep, port is defined a *DIGIT (zero or more digits).

> linux
> linux.cis.nctu.edu.tw
> www.ukweb.com
> 
>   These are the most bizarre.  The actual logfile entries claim they are 
>   coming from "linux.cis.nctu.edu.tw" and "www.ukweb.com" respectively, 
>   and they appear to be robotic in nature, yet they have the User-Agent 
>   set to valid Mozilla user-agents (like Mozilla/3.0b2 (X11; I; Linux 
>   1.3.94 i586), sometimes i486)) sometimes going via a proxy server, 
>   sometimes not.  I'm almost wondering if this is a bug of some sort - 
>   I've sent mail to Mark and to the .tw mirror maintainer (this is a 
>   mirror I had not been informed of, and isn't on our pages yet) to see 
>   if it's really from them, or if some sort of corruption from the 
>   Referer: field is coming in somehow.

The Host header field was temporarily unstable while we were trying
to figure out whether Host should apply to the proxy or the destination.
The final decision was that, in order to live with 1.0 proxies, the
1.1 clients must always give the final destination in Host.

>   This is a protected service so I can't see what type of response these 
>   people really got - both requests came from "www.tracer.com".  Maybe 
>   Netscape 2.0 doesn't change the value of the Host: header after a 302 
>   or 303 redirect?

Yikes.  Should it?  Seriously, I don't think this was considered while
drafting the Host spec.  Suggestions would be appreciated.

> From all of these, I get the feeling that handling bogus Host: headers is 
> going to be an interesting situation.  Since the migration path will not 
> be smooth, one option I'd like to have is to be able to, on the absence 
> of a Host: header or the existance of a bogus one, return an error, 
> something like "Malformed Request".  Roy will no doubt have opinions on 
> this.  :)

    400 Get a new browser, dufus

would be popular. ;-)

I suggest that you only send an error message when the URL cannot
be disambiguated in some other (convenient) way.

.....Roy