Handling ambiguous requests

I will probably do the following: when you configure the server, you
can map any host names to given roots. In addition I will have a
(mandatory) default host (eg *default-root*) to handle ambiguous
requests, or IP based requests. More pragmatically, I will do a string
based comparison on the registered host names, against the given
Host header, if none of them match, then I will fallback to the
default root.

As Jigsaw is so flexible ;-) this default root can be anything,
including a redirection to some more specific resource, emitting an
error message, etc.

Anselm.

Patrick Montelo writes:
 > Implementation Question: Handling ambiguous requests
 > 
 > For a HTTP/1.1 origin server that does differentiate resources based on the
 > host requested, certain requests can be ambiguous.  Consider the following:
 > 
 > Example 1:
 > 
 > A single server, IP address 204.4.214.77, has been configured to serve for
 > two different host names on the same port:
 > 
 > pmontelo.spyglass.com:80
 > pmontelo.foobar.com:80
 > 
 > The following requests are ambiguous:
 > 
 > GET http://204.4.214.77/ HTTP/1.1    <<< IP maps to more than one domain
 > name/alias
 > GET http://pmontelo/ HTTP/1.1        <<< Request from inside the
 > spyglass.com domain
 > 
 > 
 > Example 2:
 > 
 > A single server, IP address 204.4.214.77, has been configured to serve for
 > two different host names on the same port:
 > 
 > pmontelo.spyglass.com:80
 > foobar.spyglass.com:80
 > 
 > Consider these request:
 > 
 > GET http://204.4.214.77/ HTTP/1.1    <<< IP maps to more than one domain
 > name/alias, ambiguous
 > GET http://pmontelo/ HTTP/1.1        <<< Request from inside the
 > spyglass.com domain, OK?
 > 
 > My initial reaction is to respond with a 400 for all of these requests
 > except the last example, which would map to pmontelo.spyglass.com:80.
 > 
 > This forces the webmaster to explicitly solve any ambiguity in the server
 > configuration.
 > 
 > Anyone have any better ideas or see any problems with this approach?
 > 
 >

Received on Friday, 6 September 1996 06:23:58 UTC