On Wed, 30 Nov 2005, Jorey Bump wrote:
Can anyone conceive of a use case where it would be alright to rely on this value, even when it's been arbitrarily populated by a client-supplied absoluteURI (via a proxy, for example)? What would a developer expect to be contained in this value? For myself, I would prefer it to be a high-level interface to req.headers_in['Host'], in which case, None would be somewhat meaningful.
req.hostname is the value of hostname in httpd's req_rec structure.
Even better, deprecate req.hostname
well... this is the wrong list for this - req.hostname just reflects the value of req_rec->hostname, you'd have to suggest the deprecation to [email protected] :)
in 3.2, where we can add req.host to contain the value in req.headers_in['Host'].
The only "value" I see in this is saving 14 keystrokes.
Finally, I'm getting the impression that most developers are looking for a portable way to get the ServerName
Keep in mind that ServerName doesn't always exist, but req.server.server_hostname is the right place to get it.
req.add_common_vars() servername = req.subprocess_env['SERVER_NAME']
That's a waste of CPU cycles, since add_common_vars() copies it from req.server.server_hostname (most likely, haven't check for sure)
So, getting back to Nicolas' original post, and reaffirming Grisha's point that req.hostname isn't appropriate in his script, maybe req.server.server_hostname will work, in that it allows one to construct an URL that gets the user back to the site, even if it doesn't exactly match the URL displayed in the browser during the original request.
Good point... I won't comment on this since I believe that URL-deduction is the wrong approach to begin with ;-)
Does the fact that this is a difficult discovery warrant the addition of another high-level attribute, req.servername?
Why introduce redundancy if there already is req.server.server_hostname? Grisha
