optional format uri validation

26 views
Skip to first unread message

Daniel Davidson

unread,
Sep 11, 2013, 10:38:30 AM9/11/13
to json-...@googlegroups.com
Looking to add support to optional format schema, starting with the test format.json. In that test:

    {
        "description": "validation of URIs",
        "schema": {"format": "uri"},
        "tests": [
            {
                "description": "a valid URI",
                "data": "http://foo.bar/?baz=qux#quux",
                "valid": true
            },
            {
                "description": "an invalid URI",
                "data": "\\\\WINDOWS\\fileshare",
                "valid": false
            }
        ]
    },

It seems ruby URI.parse says this is an invalid uri. I'm doing this in Dart and the Dart parse accepts it fine.
I asked about this on the Dartlang Misc newsgroup, Valid Uri Question, and the response was it is a valid local URI.
I know the regex of the spec accepts it - so should this second test really fail?

Thanks
Dan

Geraint

unread,
Sep 12, 2013, 6:30:17 AM9/12/13
to json-...@googlegroups.com
Have you raised this on the GitHub repo for the test suite?  The people who run that seem pretty responsive.

It looks like the latest version of the URI format spec (RFC3986) allows back-slashes without percent-encoding, even though the previous version (RFC2396) didn't.

So (as far as I understand it) the point made on that group is that the backslash has no special meaning in URIs - it's not banned, but it has no special behaviour.  The string "\\\\WINDOWS\\fileshare" is not conceptually different to "__WINDOWS_fileshare", and is therefore a valid relative URI (pointing to a rather awkwardly-named file, presumably).

I'd say it's highly unwise to use backslashes in URIs - some environments (e.g. some browsers) might silently rewrite to forward-slashes, some might pass it through and cause you trouble later on, and some might just explode.

Much though I would personally *like* to ban that rather distasteful URI, I believe it is technically valid.  Unless we can justify banning it, my favourite option would be to remove it and never speak of it again. :(
Reply all
Reply to author
Forward
0 new messages