This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently "user:password" is an optional feature and I would rather kill support for it entirely than leave it as such. Now it cannot be tested basically. Can we do this?
How do implementations currently behave in this case?
Webkit/Gecko both allow it. Opera prompts the user and does not let the user/password arguments of open() override it. I believe Internet Explorer does throw, but I cannot test it.
Turns out Internet Explorer 9 does not throw (reportedly). I think the simplest way forward is to remove If the "user:password" format in the userinfo production is not supported for the relevant scheme and url contains this format raise a SYNTAX_ERR and terminate these steps. from the specification and let the URL parsing specification handle the details as to whether such URLs resolve or not. For http/https they probably ought to resolve given the implementations that support them and I will add tests to the test suite for that.
IE9 doesn't support this syntax (it follows http://support.microsoft.com/kb/834489). The IE9 preview builds only demonstrate the platform and don't impose many security constraints including this one. The underlying web browser control platform makes this an option for the host application. When Internet Explorer is the host, the constraint is enforced.
Adrian, sorry for not following up, does that mean IE does not support it in any URL, regardless of the scheme?
I think we still support it for ftp://.
So I guess this is really a URL "bug". And about whether userinfo in an http/https URL should render it invalid. Only Internet Explorer appears to do this so I'm inclined to call it a bug in Internet Explorer unless there are particularly compelling reasons for everyone to align with their behavior.
The situation in specs land is now as follows: user:password support is mandatory.