Jorey Bump writes:
> > o req.hostname is set by the contents of the full URI, or in absence
> > of a full uri, the value of the Host header (this is what is
> > actually said in the mod_python docs). As mentioned before, in the
> > case when HTTP/1.1 AND the full URI are not specified, req.hostname
> > can be None.
>
> I don't see where you confirmed this by using an absoluteURI but a
> different hostname in the Host: header.
What, you won't take my word for it? :-)
In each of the following I connect to localhost on port 8000 using
telnet. In none of the requests do I actually specify localhost or
port 8000 in the full URI or Host header to demonstrate the
arbitrariness of the client-specified values. Also, I turned off the
basic auth to simplify the examples.
---------------------------------
Full URI != Host Header, HTTP/1.1
---------------------------------
Request:
GET http://crap:666/~dpopowich/py/parsed?a=b&c=d#here HTTP/1.1
Host: foo:999
Response:
req.hostname: crap
req.unparsed_uri: http://crap:666/~dpopowich/py/parsed?a=b&c=d#here
req.parsed_uri: ('http', 'crap:666', None, None, 'crap', 666,
'/~dpopowich/py/parsed', 'a=b&c=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=b&c=d
----------------------------------
Partial URI, Host Header, HTTP/1.1
----------------------------------
Request:
GET /~dpopowich/py/parsed?a=b&c=d#here HTTP/1.1
Host: foo:999
Response:
req.hostname: foo
req.unparsed_uri: /~dpopowich/py/parsed?a=b&c=d#here
req.parsed_uri: (None, None, None, None, None, 999,
'/~dpopowich/py/parsed', 'a=b&c=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=b&c=d
----------------------------------
Full URI != Host Header; HTTP/1.0
----------------------------------
Request:
GET http://crap:666/~dpopowich/py/parsed?a=b&c=d#here HTTP/1.0
Host: foo:999
Response:
req.hostname: crap
req.unparsed_uri: http://crap:666/~dpopowich/py/parsed?a=b&c=d#here
req.parsed_uri: ('http', 'crap:666', None, None, 'crap', 666,
'/~dpopowich/py/parsed', 'a=b&c=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=b&c=d
----------------------------------
Partial URI, Host Header; HTTP/1.0
----------------------------------
Request:
GET /~dpopowich/py/parsed?a=b&c=d#here HTTP/1.0
Host: foo:999
Response:
req.hostname: foo
req.unparsed_uri: /~dpopowich/py/parsed?a=b&c=d#here
req.parsed_uri: (None, None, None, None, None, 999,
'/~dpopowich/py/parsed', 'a=b&c=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=b&c=d
-------------------------------------
Partial URI, no Host Header; HTTP/1.0
-------------------------------------
Request:
GET /~dpopowich/py/parsed?a=b&c=d#here HTTP/1.0
Response:
req.hostname: None
req.unparsed_uri: /~dpopowich/py/parsed?a=b&c=d#here
req.parsed_uri: (None, None, None, None, None, None,
'/~dpopowich/py/parsed', 'a=b&c=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=b&c=d
> IOW, the uparsed URI is just another client-supplied string, like
> Referer, and should be treated as an untrustworthy source that may
> occasionally contain interesting information.
Well put. And for me, and I think others, this is what was not known
and is now realized. I think a note should be added to the doc for
parsed_uri in section 4.5.3.2 of the manual to avoid this confusion
and let developers know it is not a bug there being so many Nones.
Daniel Popowich
---------------
http://home.comcast.net/~d.popowich/mpservlets/
