Re: [whatwg] URL: file URL C| quirk
On 7/4/2013 5:18 AM, Anne van Kesteren wrote: Both Gecko and Chromium have a quirk with C| and similar patterns (drive letter followed by |). They treat it similarly to C:. However, Internet Explorer does not do this. Should we remove this quirk? In my testing IE does treat C| as C: _if_ the scheme is qualified, as in: file://c|/foo/bar I know that including the scheme is a slightly different test case than your original, but in case it's helpful see: http://web.lookout.net/2011/06/some-browsers-convert-pipe-to-colon-in.html thanks, Chris Weber
Re: [whatwg] URL testing
On 11/23/2012 10:11 PM, Michael[tm] Smith wrote: I wonder if it might make more sense for the URLs being tested for all those cases to include a / for the pathname. That way they would be further isolated to just testing what they're actually intended to test, rather that what they're instead inadvertently testing currently (the problem of the / being appended). You're right, and it looks like this was a bug during my conversion of the Webkit test cases which did actually concat the trailing / in some tests like host.js. I've sent a pull request with the changes described above. Awesome, thank you! -Chris
Re: [whatwg] URL testing
On 11/24/2012 1:34 AM, Anne van Kesteren wrote: This is super awesome. Glad you continued with this. I have a few generic points for now: * No special handling for IPv4. IPv4 should work the same as domain names. I.e. the host of http://192/ is 192, not 0.0.0.192. * It's still a bit unclear to me what the best solution is for fragment identifiers. Whether they should be percent escaped or not and whether that should differ between .href and .hash. There also appears to be some differences in Unicode normalization (assuming I tested this enough), see: http://web.lookout.net/2012/03/unicode-normalization-in-urls.html In my tests: Safari applied NFC normalization to the path, query, and fragment. Chrome applied NFC normalization to the fragment only. MSIE, Firefox, and Opera did not apply normalization anywhere. * IDNA is a rathole. But it makes for interesting test cases :-) When are you planning on doing the further cleanup you mention? At some point I can try to go through them in detail and suggest fixes (e.g. via a pull request). I plan to do it slowly over the course of the next week or two. - Chris
[whatwg] URL testing
Hello, I've been trying to follow Anne's work with the URL spec, and working on using the W3C testharness.js for URL testing. I have some URL testing running, with still more work to do: http://www.lookout.net/test/url/ The test cases and harness are available at: https://github.com/cweb/url-testing I've aggregated about 600 test cases and their expected results from several sources, and converted them into JSON format (urls.json). A majority come from Webkit's fast/url suite as referenced in the urls.json file. A few test cases had to be modified to suit JSON, but not many. If this is of use to you I'm happy to hear your suggestions and make adjustments to the test cases, format, or approach. I do have plans to narrate each test case with a descriptive comment, reduce duplication, and add more distinct cases. Another goal I have is to look beyond the DOM, and capture a test case's resultant HTTP request as it appears on the wire, or at the server. Capturing the HTTP request would make it possible to compare a test case's path, query, and hostname components in the HTTP GET request, with he DOM's representation of the same test case - to find discrepancies between the two. Best regards, Chris
