-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change path parsing for non-special URLs #213
Conversation
@domenic this is ready for review too, but note that it builds on top of the opaque host change. |
This allows paths to be empty for non-special URLs and also takes that into account when serializing. Tests: web-platform-tests/wpt#4586. Fixes #212.
5e6d4e5
to
cea4ff8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to wait until web-platform-tests/wpt#4586 are rebased before reviewing further
<ol> | ||
<li><p>If <a>c</a> is "<code>\</code>", <a>syntax violation</a>. | ||
|
||
<li><p>Set <var>state</var> to <a>path state</a> and if <a>c</a> is neither "<code>/</code>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This really seems like it'd be better as two steps.
This does not quite match the tests yet. I noticed that the spec does not appear to match the parse path start changes in #212 (comment). You can see the spec translated into whatwg-url at jsdom/whatwg-url#70. The failing tests are:
|
I rewrote the path start changes to be a little neater, they should be identical. I found a fault in your code elsewhere that I think is more likely responsible for the failures you are seeing. |
I still get two failures I find a little harder to narrow down. Investigating. |
It seems those two failures were actually broken tests. Fixed in the web-platform-tests PR. Provided a patch in the whatwg-url PR. Will address your style nit here and then I think we're back to all good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed whatwg-url and now things look good to go.
@achristensen07 I assume you are tracking this in WebKit? I filed no bugs on other browsers since they're not actively implementing this part of the standard yet. |
Yep, I'm following this. I actually needed to implement this a few months ago to maintain compatibility. It was implemented in pieces as I found the compatibility issues. |
This changes to the way path parsing for non-special URLs. It allows paths to be empty for non-special URLs and also takes that into account when serializing. Fixes: nodejs#11962 Refs: whatwg/url#213
This changes to the way path parsing for non-special URLs. It allows paths to be empty for non-special URLs and also takes that into account when serializing. Fixes: #11962 Refs: whatwg/url#213 PR-URL: #12058 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com>
This changes to the way path parsing for non-special URLs. It allows paths to be empty for non-special URLs and also takes that into account when serializing. PR-URL: nodejs#12507 Fixes: nodejs#11962 Refs: whatwg/url#213 Reviewed-By: James M Snell <jasnell@gmail.com>
This changes to the way path parsing for non-special URLs. It allows paths to be empty for non-special URLs and also takes that into account when serializing. PR-URL: #12507 Fixes: #11962 Refs: whatwg/url#213 Reviewed-By: James M Snell <jasnell@gmail.com>
This allows paths to be empty for non-special URLs and also takes that
into account when serializing.
Tests: web-platform-tests/wpt#4586.
Fixes #212.