Add proper canonicalization of domain names #255
Closed
+20
−8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#233) Per https://whatwg.org/working-mode#anchors this is being done to ensure anchors to these concepts continue to work into the future. Resolves whatwg#231.
These examples form the only quick reference material in the spec. While MDN goes into more depth, brief explanations of what is happening in this syntax don't take up much room and may make it easier to tell what's going on, especially with regexp parts. The example explaining pattern strings is also expanded to be explicit that regular expressions are enclosed in parentheses. Resolves whatwg#229.
Per discussion on whatwg#182 some text explaining this would be useful. This mostly consists of advice since the useful algorithms are already exposed.
This PR fixes pathname processing for inputs that have opaque pathnames.
This PR fixes pathname processing for inputs that have opaque pathnames. (Amended by editor to apply to the correct draft.)
Reverting the review draft change caused a commit that the deploy script doesn't like. This one doesn't change that file so should succeed.
Use the basic URL parser when parsing URLs Blob handling is not required, since the resulting URL is not stored in any way that would make the blob handling visible. This is consistent with what the URL constructor and similar uses do. This change should not be observable. Partially addresses whatwg#242.
Editorial: Correct "set" to "let" These uses introduce the variable, so must be "set".
If the URL's host is an IP address, the string representation is required. This corrects/clarifies existing behavior.
The current specs only handle host canonicalization for IP addresses and opaque hostnames but if an URL has a special scheme its host should be normalized as a domain name (IDNA processing). Cf. whatwg#220
|
I think this will be fixed by #252. The dummy URL will have a special scheme. |
|
Fully resolved by #269 |
|
I think supporting opaque hosts might still be a good change. |
|
@annevk Then I might resubmit another PR to treat all non-empty non-special scheme as having opaque hosts. Does that sound like a good default behavior ? Some additional tests for WPT might be needed too. |
|
Yeah, I think that would be reasonable. |
|
Agree, the current spec and tests don't consider opaque hosts, but ideally we should support it.
It sounds a good direction! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current specs only handle host canonicalization for IP addresses and opaque hostnames but if an URL has a special scheme its host should be normalized as a domain name (IDNA processing).
Cf. #220
[{ "hostname": "xn--caf-dma.com" }], inputs=[{ "hostname": "café.com" }]; Pattern:["http://🚲.com/"], Expected:{ "protocol": "http", "hostname": "xn--h78h.com", "pathname": "/" }.(See WHATWG Working Mode: Changes for more details.)
Preview | Diff