Gregory (Grisha) Trubetskoy writes: > > On Tue, 29 Nov 2005, Nicolas Lehuen wrote: > > > If I understand you correctly, req.hostname is not reliable in case where > > virtual hosting is not used. What about server.server_hostname, which seems > > to be used by the code from mod_rewrite you posted below ? Can it be used > > reliably ? > > I don't think so. > > if I do this: > > telnet some.host.com 80 > > GET /index.html > > How would apache know what the hostname is?
By the Host header. I've been looking into this issue tonight and think I have the answers (but it's really late, so I'll save the gory details for tomorrow). In brief: typically, req.hostname is set from the Host header and, in fact, when I telnet to apache and issue a GET by hand, if I don't send the Host header, apache barfs with a 400, Bad Request, response. (apache 2.0.54, debian testing) As for the larger issue at hand: the reason req.parsed_uri is not filled in is because browsers don't send the info in the GET, e.g., browsers send this: GET /index.py?a=b&c=d HTTP/1.1 not GET http://user:[EMAIL PROTECTED]:80/index.py?a=b&c=d#here HTTP/1.1 if they did, parsed_uri would be filled in. req.unparsed_uri is whatever the "word" after GET in the http protocol exchange; req.parsed_uri is the parsing of that "word." Given the full URI spec: SCHEME://[USER[:[EMAIL PROTECTED]:PORT]/PATH?QUERY#FRAGMENT you can see where eight of the nine elements of the parsed_uri tuple come from; the ninth, hostinfo, is the combination of [USER[:[EMAIL PROTECTED]:PORT] (everything between "//" and "/"). Unfortunately, browsers only send: /PATH?QUERY and that's why we only ever see it in unparsed_uri and parsed_uri. Again, lots more to share...in the morrow... Daniel Popowich --------------- http://home.comcast.net/~d.popowich/mpservlets/
