W3C home > Mailing lists > Public > uri@w3.org > October 2012

Re: URL parser in JavaScript

From: Mike Brown <mike@skew.org>
Date: Mon, 15 Oct 2012 02:45:44 -0600 (MDT)
Message-Id: <201210150845.q9F8ji2s034012@chilled.skew.org>
To: uri@w3.org
CC: karld@opera.com
Karl Dubost wrote:
> > As a first step towards properly defining URLs I wrote a web-compatible URL parser in JavaScript: https://github.com/annevk/url
> — http://twitter.com/annevk/status/247749394093457408
> [...]
> > URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority().
> — http://medialize.github.com/URI.js/

Oh wow, I didn't know there were more JavaScript URI libraries out there now. 

I'd like to incorporate their relative reference resolution functions into my 
in-browser test suite at <http://skew.org/uri/uri_tests.html>, but I don't 
know when I'm really going to get around to doing it, so don't hold your 

Currently I only have 3 implementations being tested:
- one I wrote
- one TimBL wrote
- a fork of one Nathan Rixham wrote (I had to fix an infinite loop bug)

None of them are perfectly compliant implementations.

Also, as noted on my test page, I noticed that I was expecting some "wrong" 
results for one of the obscure edge cases (base URI has a scheme + a relative 
path, no leading "/"). Actually what I am expecting is the reasonable result; 
it's just not what RFC 3986 says we should get.

When RFC 3986/STD 66 was in development, Graham Klyne had reported this issue 
and suggested that the resolution algorithm be adjusted to provide a more 
reasonable result. There was no argument, so I assumed that the final draft 
would incorporate the necessary fixes. I was wrong.

Received on Monday, 15 October 2012 08:46:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:16 UTC