I've noticed that we have planned to add the missing rpath() method post-2.0, but we don't even provide a backcompat function. It's a custom convenience method provided by mp1.[...]
It should be trivial to add it, but I'm not sure where it belongs. Since path_info (which it needs to get rpath) is a request_rec member, rpath can't belong to APR::URI, as the latter is non-specific to Apache. So the only thing I can think of is to make it $r->rpath, but we won't be able to provide a back-compat function which was called on Apache::URI object, since there is no $r object (well, unless +GlobalRequest is on).
Actually it's possible to have $uri->rpath, if $uri is returned by parsed_uri, since it uses modperl_uri_t which is a "subclass" of apr_uri_t:
/* subclass apr_uri_t */
typedef struct {
apr_uri_t uri;
apr_pool_t *pool;
char *path_info;
} modperl_uri_t;So it still looks like apr_uri_t but it has more info inside.
static MP_INLINE
apr_uri_t *mpxs_Apache__RequestRec_parsed_uri(request_rec *r)
{
modperl_uri_t *uri = modperl_uri_new(r->pool); uri->uri = r->parsed_uri;
uri->path_info = r->path_info;return (apr_uri_t *)uri; }
So I suppose it should belong to the APR::URI manpage, but explicitly document that it is available only when called on an object returned by $r->parsed_uri.
And later on we may add the path_info accessor as well, so one will be able to get/set it, and by setting it, making rpath() working in a non-Apache environment too. Though it may be confused with the existing $r->path_info.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
