[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Fwd: Re: [Issue 1910] URL autoescape and IRI support]

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-06-09 20:16:44 CEST

Re-sending to the dev list.

-----Forwarded Message-----
From: Peter N. Lundblad <peter@famlundblad.se>
To: sussman@tigris.org
Cc: lundblad@tigris.org
Subject: Re: [Issue 1910] URL autoescape and IRI support
Date: Wed, 09 Jun 2004 19:58:00 +0200

> ------- Additional comments from sussman@tigris.org Tue Jun 8 17:16:34 -0700 2004 -------
> Assigning to 1.1-consider as part of the 1.1 issue-sweep.
>
> Well, we can at least *consider* it for 1.1, right? We need to chat on the list
> about how much work this requires. It will certainly be appreciated by users.
>
I think this is prety simple. Since we are already in UTF-8 (*), we just
need to escape bytes >=0x80 to support IRI:s.

I was thinking along the lines of:
svn_error_t *
svn_path_uri_from_iri (const char **uri, const char *iri, svn_boolean_t
escape_disallowed);
(or maybe the IRI as return value if we don't do any error checking.)

The boolean would tell if we auto-escape illegal ASCII characters like
space.

Then use this in the cmdline client.

Long-term we could use (legal) IRI:s internally, only escaping them when
using them in protolcs like HTTP that expect URIs. This would, for example
lead to more userfriendly error messages. This needs more consideration
though. The good thing about this is that an URI is an IRI, per
definition, so in the API:s this would be backwards compatible as far as
input parameters are conserned.

Just dumping my current thoughts on this, since I have got other things to
do right now...

Regards//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 9 20:19:17 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.