[apreq] uri_decode/encode

[david reid <da...@jetnet.co.uk>]

Having looked at these, they're small and self contained and would seem
to be a good fit for apr-util. Question is where/how would they go in?
The functionality revolves around uri's, but I'm not sure the existing
apr_uri_ stuff is a sensible match...

Once we have an answer I'll submit a patch :-)

-- 
david

http://feathercast.org/

Re: [apreq] uri_decode/encode

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 8/1/06, david reid <da...@jetnet.co.uk> wrote:
> Having looked at these, they're small and self contained and would seem
> to be a good fit for apr-util. Question is where/how would they go in?
> The functionality revolves around uri's, but I'm not sure the existing
> apr_uri_ stuff is a sensible match...

I'd still call it apr_uri_encode and apr_uri_decode.  There's no need
to confuse downstream developers - let's just be honest about what it
does.  Anything else overcomplicates it.  -- justin

Re: [apreq] uri_decode/encode

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

On Tue, Aug 01, 2006 at 11:23:12AM +0100, Nick Kew wrote:
> Which reminds me, support for *relative* URLs still isn't in apr_uri,
> and I've been shipping it separately for years in apps that need it.
> Anyone object to the attached patch going in?

Still yes, it doesn't support relative URI resolution as defined (very 
precisely) in the RFC.

joe

Re: [apreq] uri_decode/encode

[david reid <da...@jetnet.co.uk>]

Nick Kew wrote:
> On Tuesday 01 August 2006 10:07, david reid wrote:
>> Having looked at these, they're small and self contained and would seem
>> to be a good fit for apr-util. Question is where/how would they go in?
> 
> +1 in principle, and I agree apr_uri is not a great match.
> Maybe it would fit as a new apr_uriencode source file in the /uri/ directory?

Right, but what would the functions be called? Also, I image we would
provide a way to encode/decode the relevant parts of the apr_uri
structure...

david

Re: [apreq] uri_decode/encode

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

On Tuesday 01 August 2006 10:07, david reid wrote:
> Having looked at these, they're small and self contained and would seem
> to be a good fit for apr-util. Question is where/how would they go in?

+1 in principle, and I agree apr_uri is not a great match.
Maybe it would fit as a new apr_uriencode source file in the /uri/ directory?

> Once we have an answer I'll submit a patch :-)

Which reminds me, support for *relative* URLs still isn't in apr_uri,
and I've been shipping it separately for years in apps that need it.
Anyone object to the attached patch going in?

-- 
Nick Kew