@-notation was never legal in HTTP URLs anyway


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:

      http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.

(Emphasis mine.)

So there are now three sides to the argument:

  • "I want Internet Explorer to be backwards-compatible with my invalid URLs." (These people want the @-syntax retained.)

  • "I want Internet Explorer to be more secure." (These people want the @-syntax removed.)

  • "I want Internet Explorer to be more standards-compliant." (These people also want the @-syntax removed.)

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)
  1. 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.

  2. 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.

  3. CC says:

    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).

  4. John Brown says:

    The ‘@’ symbol implicitly advocates the hegemony of hierarchical/colonialist Western institutions of social control and should therefore be considered deprecated.

  5. Wayne says:

    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.

  6. Louis Parks says:

    So far as I’m aware, it @-notation was only removed for HTTP URLs. Using it with FTP URLs is still OK.

  7. Smelly says:

    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.

  8. David Cumps says:

    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)

  9. brian says:

    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.

  10. 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.

  11. (6) says:

    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’.

  12. Shane King says:

    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).

  13. Norman Diamond says:

    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.

  14. 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…

  15. 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!)

  16. Pavel Lebedinsky says:

    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.

    But at least the address bar display is fixed now, even if you re-enable basic auth URLs with the registry keys mentioned in the KB article.

  17. RichB says:

    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.

  18. Norman Diamond says:

    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.

  19. Shane King says:

    "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).

  20. Centaur says:

    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.

  21. Petr Kadlec says:

    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.)

Comments are closed.