Re: [xml] Incorrect handling of non-hierarchical URIs?

RFC 3986 introduced ABNF for URIs. In doing so, they resolved ambiguities in RFC 2396, one of which was the handling of query/ fragment components of a URI.

After again reading both RFCs, I can see the confusion and am not so certain that I would've coded URI parsing differently than LibXML2 has. In any case, since they've clarified the issue (which results in much more consistent handling), I'll file a bug with a suggested fix.

Brendan Dixon
brendandixon mac com

On May 16, 2005, at 2:36 AM, Daniel Veillard wrote:

On Sun, May 15, 2005 at 04:31:07PM -0700, brendandixon mac com wrote:

In making some tests and scanning the code (LibXML2 2.6.7), it
appears that xmlParseURIOpaquePart (and possibly the routines that
build URIs) is slightly incorrect: RFC 3986 (and I don’t believe this
has changed since RFC 2396 etc.) states that, for non-hierarchical
URIs, the path component consists of all characters up to the ‘?’
after which it is parsed the same as hierarchical URIs. That is, what
LibXML2 calls the “opaque” part is really a non-hierarchical “path”
and it may be followed by a query and fragment component.

I have two questions: First, has anyone else encountered and fixed
this? :) Second, if not, does anyone have a sense for the impact such
a change might have on LibXML2 and its community? Parsing out the
query and fragment components outside of LibXML2 for these opaque
paths might be problematic if they contain interfering escaped
characters (that LibXML2 translates).

  There is no registered/known bug concerning URI parsingC in the
current version 2.6.19. If you have a problem, please provide an example
showing up in the latest version, and it will certainly be fixed. If
the bug is confirmed and there is a patch associated usually the fix is
even faster.
I'm a bit surprized that there would be a big error in the conformance to 2396, this has been checked quite a lot, maybe it's in a not frequently
used part. In any case try to provide an example, see testURI.c in the
distribution as a starting point.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com | libxml GNOME XML XSLT toolkit http:// | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]