Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
I don't know what the specific issue is with parsed_uri, if this is a
mod_python bug it should just be fixed BUT if this is an issue with
httpd, I don't think we should cover the problem up by having
mod_python "fix" it. Since we are part of the HTTP Server project, we
should just fix it in httpd.
Either way, it should be fixed.
I think maybe it's not really broken.
In case anyone is not familiar with the issue, a request for
http://example.com/tests/mptest?view=form currently gives a tuple that
looks something like this:
That's not true. That's what you might see in your client browser, but
(usually) it only asks for /tests/mptest?view=form, regardless of the
name it used to find the server. It may use the Host: header to
negotiate the right virtual host, but the Host: header is not part of
the string that parsed_uri is actually parsing.
(None, None, None, None, None, None, '/tests/mptest', 'view=form', None)
which is not what we expect. This is what the mod_python docs have to say:
parsed_uri
Tuple. The URI broken down into pieces. (scheme, hostinfo, user,
password, hostname, port, path, query, fragment). The apache module
defines a set of URI_* constants that should be used to access elements
of this tuple. Example:
fname = req.parsed_uri[apache.URI_PATH]
(Read-Only)
This is all correct. I think the problem is that developers are hoping
to use parsed_uri in a use case for which it is inappropriate. Those
values are populated *if present* in the supplied request URI, but the
only *minimal* requirement would be a "/" for the path.
If you want to know what resource the client *really* requested (and
inquiring minds do), you *must not* attempt to rewrite or repopulate this.
