Nicolas Lehuen wrote:
2) Server name
Thanks to Daniel's excellent posts, I can see that req.hostname is the
best way to get the server name so far. Unfortunately, it depends on
data sent by the client, but hey, so does the rest of the request
handling ;).
req.server.server_hostname is unambiguous, and I can't think of a
real-world situation in which it would be None. It matches the
ServerName in your Apache configuration, so won't this be a reliable
value to use when reconstructing an URL?
One thing that would be nice is to let Apache sort out this mess and
tell us what is the virtual host name it choose to serve the request.
This is my Holy Grail and I shall seek it from now on.
Ride to Camelot with req.server.server_hostname.
Ah, while I'm at it, knowing the DocumentRoot of the current VirtualHost
would be great, too. But that's another story.
req.add_common_vars()
servername = req.subprocess_env['DOCUMENT_ROOT']
4) URL or URI or whatever you choose to name the part of the resource
one the physical matters of protocol, server and port are sorted out
uri = req.uri
Note that this uri can in turn be splitted in something which is lost by
the publisher and the req.path_info field, that is IIRC that we can
assert(req.uri.endswith(req.path_info)). I don't know what req.path_info
is before the publisher kicks in, though.
Perhaps req.uri is an unfortunate name, since it doesn't represent the
entire Request-URI.
Anyway, the length of this thread shows that a bit of clarification is
required. A page named something like "What's in an URL ?" and
explaining the client-side and server-side view of the various
components of a URL are would be great. I'll try to write a draft this
week-end.
The hard part is figuring out where the HTTP spec stops and apache
starts, then where apache stops and mod_python starts, in relation to
the terminology. A worthy goal would be to try to correct
inconsistencies between apache & mod_python, at least, so that both
projects use the same vocabulary (they do in many places, already).
