on 2/21/03 1:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> On Friday 21 February 2003 16:22, Kurt Bigler wrote:
>> on 2/21/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>> On Friday 21 February 2003 15:26, Kurt Bigler wrote:
>>>> on 2/21/03 11:33 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>> On Friday 21 February 2003 13:58, Kurt Bigler wrote:
>>>>>> on 2/21/03 10:07 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>>>>> On Friday 21 February 2003 11:55, Dale wrote:
>>
>
[snip]
>> If I'm right then you could trivially include the name-hosting solution
>> when you code what you are working on. I will be glad to test it and work
>> on it as needed, but we might as well do both things at once if at all
>> possible. Only problem may be that our schedules won't coincide and the
>> process will take more time. But 9 chances out of 10 your solution will
>> just work for the name-based situation if you just keep in mind HTTP_HOST
>> as well as SERVER_ADDR.
>
> Agreed. I'll have to make sure that the HTTP_HOST variable actually contains
> the data we want, and that there isn't a better variable choice out there,
> but I don't see why it wouldn't work as expected.
Besides HTTP_HOST there is also SERVER_NAME, which _sounds_ more analogous
to SERVER_ADDR. In my test cases HTTP_HOST is the same as SERVER_NAME.
However O'Reilly CGI Programming in Perl has these descriptions:
SERVER_NAME The server's hostname or IP address.
HTTP_HOST The hostname of the server from the requested URL
(this corresponds to teh HTTP 1.1 Host field).
So HTTP_HOST is probably the way to go. It is just the host part of the
url, i.e no http:, no initial //, no file path or query string.
A couple years back I ran a predecessor of this idea past Sam (not on the
list) and he didn't balk at using HTTP_HOST, although I don't know that he
thought deeply about it.
-Kurt Bigler
