[Haskell] Re-implementing Network.URI

[Graham Klyne]

I have re-implemented the URI parser in Network.URI using Parsec rather 
than the regex library that isn't available in Hugs, and I've wired the 
result into part of my URI handling test suite.  The parser is based on the 
very latest work-in progress that is intended to replace RFC 2396 (see 
source code for refs).

The parsing is completely rewritten, and passes all my test cases.  The 
relative URI calculation ("relativeTo") is still the original code, and I'm 
noting some discrepancies with my test suite (see below).  There are some 
more discrepancies with test cases from RFC2396, that I haven't yet looked 
into.

The source file and test suite can be found here:
   http://www.ninebynine.org/Software/HaskellUtils/Network/

It is not complete, but I'm hoping I have enough working to get the HXML 
toolbox running under Hugs/Windows.  If there is any interest in adopting 
this as a more portable replacement for the current Network.URI module, 
I'll look into bringing it fully into line with the test suite.

#g
--

Test results:
[[
### Failure in: Test Relative URIs:20:1
testRelative21(abs)
expected: "file:/ex/x/q/r#"
but got: "file:/ex/x/q/r"
### Failure in: Test Relative URIs:30:1
testRelative31(abs)
expected: "file:/some/dir/#"
but got: "file:/some/dir/"
### Failure in: Test Relative URIs:36:1
testRelative37(abs)
expected: "mailto:local/qual at domain.org#frag"
but got: "mailto:local/local/qual at domain.org#frag"
### Failure in: Test Relative URIs:45:1
testRelative50(abs)
expected: "http://example/a/b/../../c"
but got: "http://example/c"
### Failure in: Test Relative URIs:46:1
testRelative51(abs)
expected: "http://example/a/b/c/../../"
but got: "http://example/a/"
### Failure in: Test Relative URIs:47:1
testRelative52(abs)
expected: "http://example/a/b/c/./"
but got: "http://example/a/b/c/"
### Failure in: Test Relative URIs:48:1
testRelative53(abs)
expected: "http://example/a/b/c/.././"
but got: "http://example/a/b/"
### Failure in: Test Relative URIs:49:1
testRelative54(abs)
expected: "http://example/a/b/c/d/../../../../e"
but got: "http://example/e"
### Failure in: Test Relative URIs:50:1
testRelative55(abs)
expected: "http://example/a/b/c/d/../.././../../e"
but got: "http://example/e"
### Failure in: Test Relative URIs:62
testRelative76
expected: "mid:m2 at example.ord/c2 at example.org"
but got: "mid:m at example.ord/m2 at example.ord/c2 at example.org"
Cases: 120  Tried: 120  Errors: 0  Failures: 10
]]


The relevant test cases are, stated as:
[test-name: base-uri expected-absuri relative-uri]

...

[testRelative21: "file:/ex/x/y" "file:/ex/x/q/r#" "q/r#"]
(but got: "file:/ex/x/q/r")

In this case, the empty fragment has been incorrectly discarded -- I think 
this may be a bug in 'uriToString'

...

[testRelative31: "file:/some/dir/foo" "file:/some/dir/#" "./#"

(similar problem)

...

[testRelative37: "mailto:local/qual at domain.org"
                  "mailto:local/qual at domain.org#frag"
                  "local/qual at domain.org#frag"]
(but got: "mailto:local/local/qual at domain.org#frag")

In this case, it appears that relative path processing is being applied 
incorrectly to a non-hierarchical base URI.

...

[testRelative50: "ftp://example/x/y" "http://example/a/b/../../c" 
"http://example/c"]
[testRelative51: "ftp://example/x/y" "http://example/a/b/c/../../" 
"http://example/a/"]
[testRelative52: "ftp://example/x/y" 
"http://example/a/b/c/./"     "http://example/a/b/c/"]
[testRelative53: "ftp://example/x/y" 
"http://example/a/b/c/.././"  "http://example/a/b/"]
[testRelative54: "ftp://example/x/y" "http://example/a/b/c/d/../../../../e" 
"http://example/e"]
[testRelative55: "ftp://example/x/y" 
"http://example/a/b/c/d/../.././../../e" "http://example/e"]

These exercise some URI path-normalization code that I have in my original 
implementation.  As far as I can tell, these are not problems with the GHC 
implementation.

...

[testRelative76: "mid:m at example.ord/c at example.org"
                  "m2 at example.ord/c2 at example.org"
                  "mid:m2 at example.ord/c2 at example.org"]
(but got: "mid:m at example.ord/m2 at example.ord/c2 at example.org")

This looks like another case of inappropriate relative path processing.



------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact