Re: Handling ambiguous requests

On Thu, 5 Sep 1996, Patrick Montelo wrote:

> 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:

Basically, I agree with Larry's suggestion since you are defining what
should be the default fallback to poorly formed user requests or HTML
anchors which are badly formed. After exhausting other alternatives you
might choose to implement, ask the user ... It gets more complex when
the bad URL is referencing an image which has no possible way for the 
user to sort out the answer.

There are a number of clever things you might do to improve the 
quality of the server product...

1. Give the server admin a way to specify the resolution ... 
2. You can't do much for the IP address but so what ... anyone who
   uses IP addresses in this context has a bigger problem to solve
3. For partial names, the referer header as well as the origin IP
   addresses could be used for hints. It seems to me to be a rare
   situation where two different real domains would have access
   to the same multi-homed server *and* both be able to use the
   FQDN subpart to reach the server.

> 
> 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

By this example I presume you mean that the user or another page 
referenced one of the above URLs resulting in HTTP:

GET / HTTP/1.1
host: 204.4.214.77

and

GET / HTTP/1.1
host: pmontelo

The net is that I believe these to be obscure and unlikely ambituities
in the context of multi-homed host usage and giving the user a choice
as part of the error response content is sufficient.

Dave Morris

Received on Thursday, 5 September 1996 17:54:12 UTC