PR#28453: apr_uri

[Nick Kew <ni...@webthing.com>]

PR#28453 contains a patch to parse URIs relative to a base URI supplied.
Anyone object if I apply it (with any updates necessary - seems to
contain tabs)?

+ * Parse a given URI, fill in all supplied fields of a apr_uri_t structure.
+ * If the given URI is relative, then resolve it using a supplied base
+ * @param p The pool to allocate out of
+ * @param base The base to resolve against
+ * @param uri The uri to parse
+ * @param uptr The apr_uri_t to fill out
+ * @return An HTTP status code
+*/
+APU_DECLARE(int) apr_uri_parse_relative(apr_pool_t *p,
+					const apr_uri_t *base,
+					const char* uri,
+					apr_uri_t* uptr);
+
+/**
+ * Resolve an already-initialised but possibly-relative URL
+ * against a given base URL.
+ * @param p The pool to allocate out of
+ * @param base The base to resolve against
+ * @param uptr The apr_uri_t to resolve
+ * @return An HTTP status code
+ */
+APU_DECLARE(int) apr_uri_resolve_relative(apr_pool_t *p,
+					  const apr_uri_t *base, 
+					  apr_uri_t *uptr);

-- 
Nick Kew

Re: PR#28453: apr_uri

[Nick Kew <ni...@webthing.com>]

On Wednesday 28 December 2005 11:04, Nick Kew wrote:
> PR#28453 contains a patch to parse URIs relative to a base URI supplied.
> Anyone object if I apply it (with any updates necessary - seems to
> contain tabs)?

Hmmm, pasting the API of that patch, I notice both functions incorrectly
return int for apr_status_t.  A quick look at the current apr_uri in /trunk/
shows it does the same: the functions are declared and documented
as returning int, but in fact return APR_SUCCESS/APR_EGENERAL.

Worth fixing at the same time, IMO.

-- 
Nick Kew

Re: PR#28453: apr_uri

[Joe Orton <jo...@redhat.com>]

On Wed, Dec 28, 2005 at 11:04:15AM +0000, Nick Kew wrote:
> PR#28453 contains a patch to parse URIs relative to a base URI supplied.
> Anyone object if I apply it (with any updates necessary - seems to
> contain tabs)?

That needs a lot more work to actually resolve relative URI references; 
the algorithm is described in the RFC.

joe