| Date: | March 23, 2004 / year-entry #111 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040323-00/?p=40113 |
| Comments: | 21 |
| Summary: | Some people are in an uproar over IE's dropping of support for @ notation in HTTP URLs. What people fail to note is that The @ notation was never legal for HTTP URLs in the first place. If you go to RFC 1738 section 3.3 (HTTP), it explicitly states: An HTTP URL takes the form:... |
Some people are in an uproar over IE's dropping of support for @ notation in HTTP URLs. What people fail to note is that The @ notation was never legal for HTTP URLs in the first place. If you go to RFC 1738 section 3.3 (HTTP), it explicitly states:
(Emphasis mine.) So there are now three sides to the argument:
Personally I think dropping support for @-notation was the right thing to do. [Raymond is currently on vacation; this message was pre-recorded.] |
Comments (21)
Comments are closed. |
Of course it was the right thing to do. Sometimes doing the right thing needs to be defended against people who have the wrong perspective. Something that’s being done quite well.
Sometimes it also needs to be timed and communicated properly as well. Something that wasn’t done all that well.
RFC1738 has been superseded by RFC2396, which removes the section 3.3 (see RFC2396 section 1), and place the RFC2396 section 3.2.2. Server-based Naming Authority as common for all URL schemes. So, @ inside the URI is legal since Windows 98.
Yup RFC2396 says .. "This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines or their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808."
.. but it looks as if someone mis-read section 3.1 of RFC1738, which describes the user:pass part but only just mentions that it is only valid with some schemes (ftp).
The ‘@’ symbol implicitly advocates the hegemony of hierarchical/colonialist Western institutions of social control and should therefore be considered deprecated.
Is the @-symbol notation still valid for ftp: URLs? According to the notice from Microsoft, only http: is affected. I can see why it was removed for http: (I’ve never used it for that purpose) but ftp://user@pass is very common.
So far as I’m aware, it @-notation was only removed for HTTP URLs. Using it with FTP URLs is still OK.
I’m fairly certain that most of those who are complaining would have complained no matter what the final determination was. Had MS kept the @ notation the very same pepople would now be bemoaning how insecure IE is because of it.
IE is more standard-compliant now, definately.
If for some reason you want to enable it to do some local dev testing: http://weblogs.asp.net/cumpsd/archive/2004/02/07/69366.aspx
It can be handy to have some localhost urls with demo passwords in for phpmyadmin for example (when you have set it up to http authentication)
Allowing @-notation in a URL wasn’t the real security problem, in my view. The exploitable hole was that you could terminate the displayed URL before the real domain was shown. Maybe your mom and dad would be confused by @-trollers, but the early string termination prompted MS to suggest that you not click on links anymore. You know, just type in the URL you want to go to.
CC: I misread the section 1 of 2396, it does exclude from superseding the specific protocols part per scheme. Thus this RFC doesn’t affect http specificities defined in 1738. This is re-enforced by RFC2616 section 3.2.2. My bad, sorry Raymond Chen, you are right, I’m wrong.
How dare anybody try to suggest that Raymond is right? Everybody knows he’s never right about anything! :) (joke, OBVIOUSLY). Keep up the good work the big ‘C’.
I think the standards compliance argument is a bit weak.
http://www.microsoft.com isn’t a valid URL either, but I doubt any mainstream browser is ever going to not just tack on the http:// bit for convenience.
I’m not exactly sure how removal of the @ symbol makes anything more secure either. The security risks from the @ symbol are social, not technical (with the exception of any bugs in URL handling).
A related security problem, which remains, is the ability to display text in the status bar that is different from the actual destination of the link. A plain technical standard could allow this with the point of view of not being a security standard. A security standard would never allow it.
But no standard gets to tell Microsoft what to do. If Microsoft decides to take security more seriously, they’ll change this too.
Shane,
You might think no mainstream browser would not just tack http:// on the front, but you’d actually be wrong.
I don’t know if this will work, and Raymond’s block lacks a preview option, but: <a href="www.microsoft.com">test</a>
If that doesn’t work you can try putting a href into a html page with just http://www.microsoft.com in the body. On my local machine when I create the html page in C:temp the URL points to file://C:/Temp/www.microsoft.com.
So you can see if you did it on a web page it’s point to whetever the base-href is + "/www.microsoft.com". Which makes sense, as it’s just a relative URL at that point…
And of course it didn’t work :(… You’ll have to try it out on your local machine… (and Raymond’s gone to remove my double post!)
While we’re being pedantic about URIs, could I do my little bit in the world to help Microsoft be more pedantic about URNs.
URNs have TWO colons in them, not one. So many times I see code from Microsoft with a single colon. urn:xxx is incorrect.
3/23/2004 8:41 PM Pavel Lebedinsky:
> But at least the address bar display is
> fixed now,
Well, it changed into confusing garbage instead of being totally misleading as before. Yes confusing garbage is safer than being totally misleading, so I’d call it partly fixed.
"You might think no mainstream browser would not just tack http:// on the front, but you’d actually be wrong."
I’m talking about when you type it in the address bar, not as a link on a web page (no browser that I’m aware of can auto-translate a href attribute, it has to assume it’s a relative path).
And that’s not always a good thing, such as when you say “ftpsearch.example.com” and it guesses it is an ftp site and tacks ftp:// on it. Predictable http:// always would be ok, but now you have to know when you can omit http:// and when you can’t.
Oops. :-o I am really surprised! I have never even thought about @-notation being not legal (and I have even implemented some URI parsers with those RFCs before me). OK, it’s not legal according to the standards, then it’s good to remove them.
But I don’t like it. Really, I see no point in it. (Why should @ be allowed in ftp: URLs and not in http: ?) OK, some naive user is not able to understand that http://www.microsoft.com@somewhere.com/ does not point to microsoft, but that’s a problem of the user, not the URL. (What if I register a domain name like http://www.microsoft.no-ip.com/ ? The same user would of course think it is Microsoft’s site.) I consider the solution of the Opera browser to be better — when you try to go to some URL that contains login information, a dialog box is shown that warns you about possible security problem, and the dialog visibly displays the username and the real site name.
I hope Opera will keep this (against the standards, I know…). But where I would really miss @-notation is wget and similar tools. OK, I would be able to write wget –login=user:pass http://example.com/, but I am used to @. :-)
(So my solution would be to make @-notation for http URLs legal, and include a note in the "Security considerations" chapter of the RFC.)