-
Notifications
You must be signed in to change notification settings - Fork 107
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
origin defaults to "null" #38
Comments
As bad as it is I think it makes sense, see https://url.spec.whatwg.org/#origin. We should return an opaque origin whose value is the |
@lpinca I'm starting to doubt here, it never says it's a string so it might have been just the |
@3rd-Eden run |
From https://url.spec.whatwg.org/#urlutils-members
and https://html.spec.whatwg.org/multipage/browsers.html#unicode-serialisation-of-an-origin
So I think we are doing it correctly. |
There is actually a case where browsers return an empty string for > var a = document.createElement('a');
undefined
> a.href
""
> a.origin
"" so maybe we can use the empty string as well when we pass an empty string to the parser? > parse('sip:[email protected]')
URL {
protocol: 'sip:',
slashes: false,
hash: '',
query: '',
pathname: '',
auth: 'alice',
host: 'atlanta.com',
port: '',
hostname: 'atlanta.com',
password: '',
username: 'alice',
origin: 'sip://atlanta.com',
href: 'sip:[email protected]' } in this case I think |
Its that technically considered an URL?
|
@3rd-Eden what are you referring to specifically? The |
I noticed that
origin
defaults to"null"
unlike any of the other default values that the parser returns and was wondering if that is intentional. Here's what I get when passing an empty string to the parser:Besides the inconsistency,
"null"
evaluates truthily, which seems potentially problematic to url-parse users.If an empty string is ultimately desired for
origin
when no value is present, I can submit a PR for that.The text was updated successfully, but these errors were encountered: