This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://url.spec.whatwg.org/#parsing If URL parser is run with input="http://foo:bar@exmple.com", base="about:blank" url=ParsedURL(input=http://aaa:bbb@example.org, base="about:blank"), its username will be "aaafoo", and its password will be "bbbbar". In authority state, following sentence should be inserted before "Set the @ flag.": Otherwise, set url's username to the empty string, and set url's password to null.
Wait, how would you get in that situation?
(In reply to comment #1) > Wait, how would you get in that situation? Only unit testing.
Okay, so I think the fix here would be to require an override state (which should probably be limited to those from the API) when you provide a parsed URL to the URL parser algorithm. Unless you mean your failure is reachable through JavaScript somehow.
Sure, you can mark this as INVALID.
Does this help: https://github.com/whatwg/url/commit/0e6b08b5458860364d0f3604ca8f7c1b9244c600
(In reply to comment #5) > Does this help: > > https://github.com/whatwg/url/commit/0e6b08b5458860364d0f3604ca8f7c1b9244c600 Oh, I see. Therefore the URL parser algorithm should have following at the first line: If url is given but state override is not given, parse error, terminate this algorithm.
Given that something like that is not valid, I'm not sure that's needed. Those arguments are specifically added for the API. If you use them in ways the API did not envision, you're in trouble :-)
Sure if it is such policy.
I think this is now sufficiently clear. http://url.spec.whatwg.org/#concept-url-parser