Jorey Bump wrote:
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.
As I review Daniel's summary and the apache code I've come to this
conclusion as well.
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.
Well, it is true for some definitions of request. :)
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.
I guess the confusion comes in part from misunderstanding the difference
between a URI, absoluteURI, relativeURI, and a URL. I think when most
developers (and by most I mean me ;) ) see the description of
parsed_uri they get excited by all the goodies contained therein, only
to find its mostly empty promises. Sorta like the great toy pictured on
the outside of the cereal box. You just *have* to dig to the bottom of
the box to get that wonderful treasure, only to discover it's some cheap
piece of plastic about the size of a pencil eraser. Oh, the
disappointment! Can any of us really trust the cereal industry ever
again? (No issues here... nope... none at all... mumble... mumble...
mumble)
Now where was I... oh, right, mod_python...
At this point I think we should leave parsed_uri alone, as it seems to
do the correct thing - if not the desired thing. At a minimum we should
expand the documentation to warn people of the limitations. I still
think it would be useful to have a tuple similar to parsed_uri, but
which is fully populated. Or maybe everyone just continues to roll there
own.
Regards,
Jim
