IE will drop support usernames in URLs

Will it be missed, or goodbye and good riddance?

[jamesa]

From this article on Netcraft [news.netcraft.com]

A forthcoming update to Internet Explorer will disallow the use of the "@" character in URLs...[snip]...Once the update is installed, including the @ symbol in urls will return an "invalid syntax error" message

Miscrosoft's workaround [support.microsoft.com] is simply not to use them, LOL.

So... will it be missed?

[txbakers]

I always avoid using special characters like that in my URLs.

[plumsauce]

It will be missed by me.

Just finished months of development on a session
tracking system that is dependent on that behaviour.
It tracks users and keeps session variables absolutely
reliably in the face of firewalls, proxies, you
name it. Internally, it behaves like cookies, but
never sends/receives cookies to the user.

Just got flushed down the toilet.

+++

[Hester]

Could you not replace the '@' character with a different one?

What about those awful urls that have stuff like "@@@@@@123_@@@629" on the end. Guess those won't work no more.

[plumsauce]

No, because it is not the character itself, but
rather the interpretation by IE that what precedes
the @ is a username. I really don't care what
character it is, but it is the fact that the
behaviour is going away that hurts.

This is, in fact, specified by the relevant RFC.

+++

[plumsauce]

here is what i just posted to the ietf working
group for http, in response to a comment by
a microsoft representative:

Is this not really a rendering problem?

This remark includes the "%01" problem,
and user perception that the leading
part before the "@" is the web site.

The first is a problem internal to the
browser, and should be fixed.

The second is a rendering problem, in
that many users do not know the difference.
Therefore, it is more useful to present
the url to the user without the credentials
portion.

If the embedded credentials are permitted
in a valid url, and that url is embedded
as, for example, the href of an <a> tag,
and the browser does not retrieve the
referenced resource, then the browser
is broken.

Removing this valid behaviour will, in some
cases, break many months of work. I am
involved in one such case.

[TryAgain]

Not saying this is a good move, but in all honesty, isn't this a very underused feature?

{The feature, not the exploit of it ;-)}

Sorry for the ones that get hurt by this though.

This must mean they really can't fix the underlying bug. Or maybe they're just lazy? I read the next release of IE will be with Longhorn, so maybe by then they can fix it, though disabling and then enabling again is not exactly the way to go.

[jamesa]

>> This is, in fact, specified by the relevant RFC.

Right. So now we have MS setting their own standard? Which will turn out to be the de facto standard? In principle that bothers me.

[TryAgain]

So now we have MS setting their own standard?

If they wait long enough with releasing another version, Mozilla will become the standard. Least one should hope so. ;-)

[amznVibe]

I take it %40 is going to still work or there are going to be thousands of broken PayPal links on the web.

[plumsauce]

Well, I was corrected by both Paul Leach(Microsoft)
and Roy Fielding(Apache) who are listed as authors
of RFC 2616.

The gist of it is that the usage of username:password
is not an acceptable part of the http uri schema,
the quote I was pointed to was:

3.2.2 http URL

The "http" scheme is used to locate network resources via
the HTTP protocol. This section defines the scheme-specific
syntax and semantics for http URLs.

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

(watch the line breaks)

So, in fact, Microsoft is changing IE in full compliance
with the standard. As I said on the IETF list, I just
gotta suck it up.

I just liked it better the old way :)

+++

[plumsauce]

And here's my latest plea to IETF, formed after I read
my last post here:

Well, I've had second thoughts.

It has occurred to me that we are really looking at
two different things, both being referred to as
URL's.

3.2.2 is really more akin to a formal specification
of what the request-uri of 5.1.2 should look like
in the HTTP protocol. Certainly, it specifies that
the host is mandatory, yet hosts are often omitted
in HTML documents.

Howver, there is nothing inherently wrong with
username:password appearing in an *HTML* document,
and the browser subsquently interpreting that
information to form a Authorization: header
in response to a WWW-Authenticate: challenge.

As we all know, [username:[e-mail]...] is not
sent literally over the wire. And neither is
[example.com:8080...]
but rather

GET /index.html?var=something HTTP/1.1
Host: www.example.com

and the client *knows* automagically to
connect to port 8080.

To make a long story short, as long as the
over the wire protocol is respected, is there
really anything proscriptive in 2616 with regard
to the appearance in an *HTML* document? The only
thing that username:password@ causes in *HTTP*
when the browser finally gets around to it,
is the addition of:

Authorization: blahblahblah

in response to WWW-Authenticate.

To go really far out in left field, there is
nothing in 2616 to stop an html author from
displaying the username/password on the page
and asking the user to key it in when challenged.
Nor does it say that IE cannot store a username
and password for the "remember password function".

If the argument is that 3.2.2 prescribes the
semantics of the href attribute of the HTML <A>
tag, then there is a lot of broken HMTL code
out there because it quite common to use
either root relative, or relative URL's in
href attributes. The fact that common browsers
know what to do about this would be due to
their interpretative abilities. By extension,
username:password@ is also an interpretive
ability.

And it's all in the HTML, it's got nothing to
do with HTTP over the wire. At least in
practical terms.

BTW, it was mentioned in a forum elsewhere
that this change would break a lot of
Paypal payment links. I don't know myself
because I do not have a Paypal vendor account.

What I am really asking is that the distinction
be made between what HTTP is, and running
HTTP from HTML documents. A minor distinction,
but perhaps a useful one.

Respectfully,
****x

[Hester]

I once saw an AOL (I think) url with the @ symbol in the middle - eg: [e-mail]. I wonder how that will work now.