Mailing-List: contact dev-help@abdera.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@abdera.apache.org
Message-ID: <703381221.1241559337832.JavaMail.jira@brutus>
Date: Tue, 5 May 2009 14:35:37 -0700 (PDT)
From: "James M Snell (JIRA)" <jira@apache.org>
To: abdera-dev@incubator.apache.org
Subject: [jira] Commented: (ABDERA-225) At ("@") and colon (":") in path
 segments should not be escaped by IRI.normalize()
In-Reply-To: <1020587363.1241530350462.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/ABDERA-225?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1270=
6206#action_12706206 ]=20

James M Snell commented on ABDERA-225:
--------------------------------------

I have a fix pending, just can't seem to be able to access the svn server a=
gain today.=20

> At ("@") and colon (":") in path segments should not be escaped by IRI.no=
rmalize()
> -------------------------------------------------------------------------=
---------
>
>                 Key: ABDERA-225
>                 URL: https://issues.apache.org/jira/browse/ABDERA-225
>             Project: Abdera
>          Issue Type: Bug
>    Affects Versions: 0.4.0
>            Reporter: Niklas Lindstr=C3=B6m
>
> The `normalize` method on IRI objects escapes ":" and "@" in path segment=
s, which doesn't seem to comply with the ABNF rules given in the IRI RFC (R=
FC 3987 section 2.2. <http://tools.ietf.org/html/rfc3987#section-2.2>).
> It seems that `isegment` explicitly *allows* for ":" and "@", according t=
o:
>     isegment       =3D *ipchar
>     ...
>     ipchar         =3D iunreserved / pct-encoded / sub-delims / ":" / "@"
> The `normalize` method encodes each segment by filtering on `CharUtils.Pr=
ofile.IPATHNODELIMS`, via `CharUtils.is_ipathnodelims`, which uses `is_ipat=
h` && `!isGenDelim`.
> The effect is that this (groovy):
>     import org.apache.abdera.i18n.iri.IRI
>     println new IRI("http://example.org/publ/1999:175").normalize()
>     println new IRI("http://example.org/people/admin@example.org").normal=
ize()
> prints out:
>     http://example.org/publ/1999%3A175
>     http://example.org/people/admin%40example.org
> , where I would expect no escaping at all. Note that:
>     println new java.net.URI("http://example.org/publ/1999:175").normaliz=
e()
>     println new java.net.URI("http://example.org/people/admin@example.org=
").normalize()
> results in the expected:
>     http://example.org/publ/1999:175
>     http://example.org/people/admin@example.org
> Since an ipath is composed of "/"-separated isegments (with some specific=
s regarding absolute, rootless and noscheme), perhaps a solution would be t=
o rework `is_ipath` into calls fully mimicking these ABNF rules, and use `U=
rlEncoding.encode(..., Profile.IPATH.filter())` in `IRI.normalize(path)`?

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.