Nicolas Lehuen wrote:
2005/11/30, Jim Gallacher <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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
Well, I'm still interested in writing a function that would return a
fully populated parsed_uri-like structure, even in the absence of an
absolute URL in the request path. Call me stubborn, but I still feel
that using a configuration item to tell mod_python the supposed
protocol, server name and listening port is a blatant breach of the DRY
principle. Plus, it would force me to change the configuration file
between my development, test and production platform...Yeah, I'm that
lazy :).
That's not lazy, it's smart. Test and production should be as similar as
is possible.
Ah, while I'm at it, knowing the DocumentRoot of the current VirtualHost
would be great, too. But that's another story.
I don't know that story. Is there a problem with req.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.
I'm not sure I understand what is being lost since publisher does not
modify req.uri. Something that I've found useful but which seems to be
missing is the idea of a base_uri, where
uri = base_uri + path_info
Or maybe the base_uri part is what you mean when you say something is lost?
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.
Excellent.
The corollary of this discussion is putting the parsed_uri back together
again. Is there any support for exposing apr_uri_unparse()?
Jim
