- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 29 Oct 2014 15:24:16 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: whatWG <whatwg@whatwg.org>, "Santiago M. Mola" <santi@mola.io>
On 10/29/14 4:47 AM, Anne van Kesteren wrote: > On Wed, Oct 29, 2014 at 12:12 PM, Sam Ruby <rubys@intertwingly.net> wrote: >> 1) Is the following expected to produce a parse error: >> >> http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 ? >> >> My reading of https://url.spec.whatwg.org/#relative-path-state is that step >> 3.1 indicates a parse error even though later step 1.5.1 replaces the non >> URL code point with a colon. >> >> My proposed reference implementation does not indicate a parse error with >> these inputs, but I could easily add it. > > Given the legacy aspect, probably should be an error. Fixed: https://github.com/rubys/url/commit/6789a5307ebd0e4aa05161c93038f2fc50011955 But it turns out that addressing that question opens up another question. In my implementation that fix caused a (recoverable) parse error to be produced for another test case: http://intertwingly.net/projects/pegurl/urltest-results/d674c14cbe I'll note that galimatias doesn't produce a parse error in this case (and, in fact, the state machine specified by the current URL Standard goes down a completely different path for this case). The question is: should this be a parse error? - Sam Ruby
Received on Wednesday, 29 October 2014 22:24:42 UTC