URLs in Internet Explorer 7

Internet Explorer 7 includes a new URL handling architecture known internally as CURI.  The new optimized URI functions provide more secure and consistent parsing of URIs to reduce attack surface and mitigate the threat of malicious URIs.

When designing our security strategy for IE7, malicious URIs were near the top of the list because secure handling of URIs throughout IE is critical to the security of the system. Hence, a major architectural investment was made in CURI for IE7.

Unlike most of the new features in IE7, most end users will never notice CURI working “under the hood” on their behalf.  For the technical readers in the audience, however, the details behind CURI may be of some interest.


Uniform Resource Locators (URLs) are one of the most important and seemingly simple concepts web users encounter.  Almost everyone recognizes a Uniform Resource Locator as the character string which allows the browser to find a website.

Uniform Resource Identifiers (a superset of URLs) were most recently formally specified in RFC3986, the fourth significant revision in the evolving definition of URIs. To quote the RFC,

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.

Pretty simple stuff, right?  Alas, as usual, the devil is in the details.

Strings vs. Objects

Given the definition of a URI, it seems natural to represent a URI as a character string. And, in fact, simple character strings are how URIs are most often stored and transferred.  For instance, to navigate to a web page, the user types a URI string into the browser’s address bar, or clicks an HTML anchor tag containing a HREF attribute whose value is a string URI.

Unfortunately, there are some downsides to using character strings to store URIs. The biggest problem is that a string is a simple data structure which only holds a sequence of characters, and contains no further information or logic for how that data should be interpreted. Having more information available about a URI is useful for a number of reasons, but security tops that list.

How the browser uses URIs

When you visit a webpage, chances are that there are dozens to hundreds of embedded resources, many of which are addressed via relative URIs. For instance, if you visit http://search.msn.com/default.aspx, the HTML source contains the following image tag:

<img src="/s/hp/bluesky_logo.gif" title="MSN" alt="MSN" height="32" width="81" />

In order for the image to be downloaded, the browser must first combine http://search.msn.com/default.aspx with /s/hp/bluesky_logo.gif to come up with a complete URI which can be downloaded: http://search.msn.com/s/hp/bluesky_logo.gif. In order to combine the base URI with the relative URI, the browser must first crack the base URI and the relative URI to retrieve their respective components.

A URI consists of multiple components, each of which helps the browser and server to retrieve the requested file.

For example, given the URI http://search.msn.com/results.aspx?q=ie7#listings

  • The scheme component is http
  • The hostname component is search.msn.com
  • The path component is /results.aspx
  • The query component is q=ie7
  • The fragment component is listings

Thus, when generating the full URI to the image, IE must combine the scheme and hostname from the base URI (http://search.msn.com) with the path of the relative URI (/s/hp/bluesky_logo.gif). As you might imagine, performing this crack-and-combine process hundreds of times per page is quite inefficient, and introduces the risk of inconsistent parsing or evaluation.


All web browsers make security decisions based upon URIs.  Many security features, from Security Zones to the JavaScript same-origin policy, depend on the browser being able to consistently evaluate URIs to determine their components, and to compare them to other URIs.

If a bad guy (or gal!) can get a browser to incorrectly or inconsistently crack or combine a URI, the user’s security may be compromised.  Over the years, a significant percentage of browser patches have been issued to address exploits against URI parsing flaws, for instance the CAN-2005-0054 vulnerability in IE, or Opera’s older %2f bug, to name but two of many.

URI-parsing attacks against Internet Explorer typically attempt to trick a security function (like MapURLToZone) into evaluating an exploit URI incorrectly (for instance, by returning the wrong security zone). If the URI is zoned into a more trusted zone than it deserves, the content at that URI might execute with elevated privileges.  Other common attacks attempt to set or steal cookies from other domains, read content from one domain and send it to another, or spoof the user by displaying the URI incorrectly.

Difficulties in securely handling string-based URIs are often rooted in the fact that there are an infinite number of possible representations for a single URI, so a simple string comparison isn’t possible. RFC3986 specifies conditions in which a character in a URI is equivalent to a percent-encoded character in the format %HH, where HH is the hexadecimal-formatted integer representation of the character. Equivalence rules vary depending on where a character appears in a URI; for instance, the scheme and hostname are case-insensitive, but paths and queries are not.

The following URIs are all equivalent:

  • http://www.example.com/sample/
  • http://www.EXAMPLE.com/sample/#
  • Http://www.ex%41mple.com/s%61mple/
  • http://www.example.com/sample/arbitrary/.%2e/

All code paths in the browser must be fully knowledgeable about the rules of URI-parsing in order to correctly evaluate a URI. Any failures could enable an attacker to circumvent security restrictions.

The Solution: CURI

CURI is a lightweight object which holds a single URI in normal form. If the CURI is constructed from a string URI, that string URI is cracked just once when the object is first constructed. After construction, callers may access any of the URI components using members provided by the object. This ensures that URIs are evaluated consistently throughout both security and feature code paths. We’ve re-plumbed Internet Explorer to accept and use CURI objects internally; most of this work has already shipped in Beta-1.

The CURI object is available for consumption by external callers like ActiveX controls and Browser Helper Objects; documentation will be provided on MSDN as the CURI class is finalized. It’s worth noting that even external code that does not directly consume CURI objects will benefit from the change, because Unicode string serialized out of CURI objects will be consistently normalized, decreasing the likelihood of incorrect parsing even outside of IE.

Future Directions: International URIs

One advantage of the centralization provided by the CURI object is that it enables future URI-handling enhancements. In particular, working with international URIs is a key scenario for Internet Explorer 7, and the fully-Unicode CURI object is the keystone for our worldwide support. International URIs are critical to the future of the web as ever more international sites come online and more of the world’s diverse languages appear on the web.

I’m not quite ready to talk about IE7’s support for International Domain Names (IDN) yet, but expect to hear more as Beta-2 approaches. In particular, we’ll be talking about how IDNs work within existing network infrastructure, and how IE7 will mitigate the threat of Unicode homograph attacks.

- EricLaw

Comments (98)

  1. Anonymous says:

    Oh, I’ve expected IE has used CURI-like objects already.

    Afterall, this is the expected OOP style of handling a functionality that’ll be used throughout the application. (And possibly "the system")

    And concerning the "Unicode Homograph attacks", as a Chinese user, I’d like to know is there any built-in function in Windows that’ll allow translation between Traditional Chinese(CHT) and Simplified Chinese(CHS)? If not, your team may want to ask other teams to build one or you can’t possibly get around the "Unicode Homograph Attacks" using Chinese characters.

    I live in Hong Kong where people use both CHT and CHS in their life, and people likely treat an address in CHS as those in CHT, therefore creating the possbility for opening a fake website with one or two characters changed to another character set.

    Even if this is too complicated to be done(I fully understand how difficult a task it could be to achieve a good effect), it’d be great if the browser can issue a warning popup to alert the user about this possible abuse.

  2. Anonymous says:

    Good to know that the URI parsing/handling will be so extensible, so next step could be data URIs.

  3. Anonymous says:

    I hope for the new optimized URI handling architecture.

  4. Anonymous says:

    I find it quite shocking that only with version seven of IE has someone at MS finally figured this out! I hope this "new-found-thought" extends to other common parts of MS too!

  5. Anonymous says:

    Sorry if I may have missed this in your post (or previous posts) but …

    A few years back, when I was first starting out in HTML and web site building, I recall that the book I was learning from stated that when using hyperlinks or referring to images (or any address for that matter) that a relative path should always be used when the resource is hosted under the same domain, as the web browser can match them up and request the resource more effectively, but after reading your post, and talk of combining and cracking each URL makes me think differently.

    So could I ask if I should in fact be using absolute URL’s for each resource within any given web page for the current fleet of IE’s or if I have just miss-read part of your post?


  6. Anonymous says:

    IDN support AT LAST!

    Only when MSIE has native support for it we can start to use IDN.

  7. Anonymous says:

    And here I was thinking, is there still somebody that doesn’t do this already..

  8. Anonymous says:

    It is really great to hear that IE7 will support IDN, and I’m interested to hear how you’re addressing the homograph problem.

    Also, will IE7 support the data: URI scheme?

  9. Anonymous says:

    Urgh. Does this really mean IE6 deals with URI only in string form ?!? Scary.

  10. Anonymous says:

    hmm, are there URLs not in string form? I’m confused&hellip;

  11. Anonymous says:

    I tried to find a wishlist for Internet Explorer but couldn’t find one. I was wondering if the new Internet Explorer will have tooltips over links like Opera.

    This is a truly remarkable thing, you point your mouse over a link and in a tooltip you have the real address to where yjat link points to. With this you can hardly make the mistake of clicking a link that will take you anywhere else that the text suggests.

  12. Anonymous says:

    All IE7 is a knock-off version of FireFox, Netscape (owner of Mozilla, which created FireFox) has always been a better internet Browser

  13. Anonymous says:

    Dear Eric,

    thanks for your reaction on mine and other posts regarding the IDN-technology.

    It is so good to hear the first official MS-statement that confirms IDN will be supported by IE 7.

    I’m very curious which solutions you’ve chosen.

    Thanks again,

    Jean Pascal

  14. Anonymous says:

    You just mentioned

    "crack-and-combine process hundreds of times per page is quite inefficient"

    This is true. But this is not dominated issue for browser efficiency with current CPU speed.(As long as it is not used in mobile).

    Need more work to solve No Response, or freeze issue. When IE7 go to Tabbed, this will become a hot complain. If one tab is freezed, at least let user switch tab.

    Mike J

  15. Anonymous says:

    Great! To-the-point talk, with references to RFCs instead of marketing material 🙂

    Don’t forget Data URI scheme! It’s very useful sometimes.

  16. Anonymous says:

    Thanks for the IDN-support!

  17. Anonymous says:

    Good work! I’m glad its coming out this way. I think you guys should open up a forum to discuss that tabbed browsing when you get a chance, or perhaps a chat session. Just my 2c.

  18. Anonymous says:

    Thanks for listening to us. IDN support is a great add-on.

  19. Anonymous says:

    Would you *please* fix your RSS feeds to include the proper character encoding? I’m tired of looking at question marks and blocks in my feed readers.

    It isn’t hard, to the top just add:

    <?xml version="1.0" charset="windows-1252"?>

    I’ve requested this a couple of times on your contact page.

  20. Anonymous says:

    CURI = ?

    Centralized Uniform Resource Identifiers ?

  21. Anonymous says:

    Please support data: URIs.

    For very little development investment, it would add some useful flexibility.

  22. Anonymous says:

    While the number of representations of a URI is not infinite, it is very large.

    Are all URIs cracked? I thought only URLs were cracked. For example, there isn’t such a thing as a relative URN, at least to my knowledge.

    I’m honestly surprised that different parts of IE weren’t already sharing the same crack routine. Security aside, that just seems like basic code reuse.

  23. Anonymous says:

    Provided you are forgiving with my english, which is not my native language, my comment is rather simple.

    I do not care where I would be placed by surfers or more seasoned web developers – whether in hell or purgatory or paradise; whether in the seclusion of the amateur, in the dregs of the parvenu, in the empyrean of the professional, or onto the paths of the lonesome geek, or even in the no man’s land of the nonsense and of the freak. I can live with my self esteem regardless of my own conceit and of the opinion of the others, and so I just go on coding.

    But to my humble experience, the outcome of it is simply one: Internet Explorer rocks.

    I spent years seeing comments of sophisticated -very sophisticated- persons who endlessly blamed IE and accused it of nearly everything, from bad weather to fixed layers, from bad digestion to limited selectors’ hovering.

    To me, css dhtml or whatever you throw at its jaws, my problems NEVER came from Internet Explorer but invariably (I want to stress this: i-n-v-a-r-i-a-b-l-y) by OTHER browsers.

    Internet Explorer has always been the browser that always behaved the expected way when COMPARED to what incredible amount of wrong behaviours other browsers were able to misdo.

    To me, this has always appeared as a FACT, whence derives the opinion, and NOT as a previously established opinion after which we go in search of facts to support it.

    So, I even dare deem it unbiased.

    When I read some comments where IE gets bashed and other browsers, clearly clustered with flaws, get worshipped, it always seemed to me there was in action either an underlying undeclared IDEOLOGICAL assumption (IE as the metaphor of greedy capitalism versus the proletarian knack of other browsers – yet still developed by billions yielding Companies, a particular conveniently overlooked) or the habit that long ago Bertrand Russell stressed with his witty sarcasm: that two plus two yields four "is an opinion that only very, very experienced philosophers would feel like contending".

    That Internet Explorer is not SIMPLY FABULOUS a browser, is an opinion that only very very experienced and very very sophisticated developers would challenge too strongly and so loudly.


    Alberto, unitedscripters dot com

  24. search-engines-web says:

    How much of this surfing information is retrievable by Microsoft – will it be used in the New MSN search ALGOs?

    ["The CURI object is available for consumption by external callers like ActiveX controls and Browser Helper Objects;." ]

  25. PatriotB says:

    Netquik asked: "CURI = ?

    Centralized Uniform Resource Identifiers ?"

    My guess is that CURI is the class name of the object itself. ("C" is a standard prefix for classes.) In other words, it is the class that implements the IUri interface that is documented at: http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/moniker/reference/ifaces/IUri/IUri.asp

  26. Anonymous says:

    Give me a break Mr Alberto.

    All the other browsers are the ones we need to blame?

    I think you aren’t beeing fair!

    What about the w3c Standards? The ones that IE DOESN’T follow?

    What about security issues?

    I’m Not a professional web developer, but since I discover and learn about the standards, I can see where MS did the wrong job, not following the standards and blaming other browsers, just like you did right now!

    So don’t spread FUD and think after talk

    PS 2 plus 2 is five (when you count wrong)

    Goood Bye

  27. Anonymous says:

    I too am rather shocked and appalled that MS has just realized, in 2005, that OOP is the way to go. No wonder IE has had so many security problems. Do I dare ask what other common code is currently implemented dozens of times?

  28. Anonymous says:

    So, the 508 character URL limit is fixed now? (for Bookmarks)

    If so, please post the new limit…

    If not, please go back to your developers and give em a good kick.


  29. Anonymous says:

    <<EricLaw, even given unlikely ../ directories in absolute addresses, it is still not infinite if there is a practical limit to the length of URLs.>>

    Hehe. I stand corrected. 🙂 I’ll refine my statement to be: There are somewhere in the neighborhood of ~40 ^ 2000 possible equivalent representations of a given URL.

    (I misspelled minuscule, above. Oops.)

  30. Anonymous says:

    The Internet Explorer team talks about URLs in IE7, and what they’re doing to prevent spoofing as much…

  31. Anonymous says:

    Guys, could you add a setting to turn off SOUNDS in IE? It drives me insane that for the last however many years I have to listen to pages loading!!!

    Whats wrong with the one that has been there for years?

    In the same place every single other setting on windows is, strange enough – they put settings all in the control panel.

    Start -> Control Panel -> Sounds and Audio -> Second Tab -> Either Edit the individual Sound on the bottom, or as I do, select the No Sound Scheme from the top drop down -> Click off on the stupid save/whatever alert that comes up after you hit apply -> Ok out


  32. Anonymous says:

    I don’t understand why this align=justify does not work for text in IE. It works perfectly well in firefox 1.0 and above. IE developers, please try to see that this option works….


  33. Anonymous says:

    I wonder if it would be worth exploring the TinyURL paradigm and creating a local database of frequent and/or common URI’s and tagging them as a shortcut. This could work in conjunction with IDN’s.

  34. Anonymous says:

    Its been a while since my last post here. I guess Beta 2 work has been taking most of my time. But I…

  35. Anonymous says:

    All I know is they’d better fix it so when I type in any url starting with "ftp" like ftpsearch.ntnu.no, it doesn’t get all smart-retarded and open it with the ftp:// protocol. Dammit, Jim, it’s a browser, not an FTP client!

  36. Anonymous says:

    It’d be nice if I enter "blah.com:81" I don’t need to enter http://.

  37. Anonymous says:

    Please start fixing the URL length limit of 2083 (= 2048 + the length of "http://www.microsoft.com/index.html&quot; ?), and support for data urls like data:image/jpg;base64 as well…

  38. Anonymous says:

    I’ve been round the blogverse and there are a lot of cool things being linked to. Seems a shame to have…

  39. Anonymous says:

    Хрень всё это. 😉

  40. Anonymous says:

    I recently found out that you’re not supposed to be able to use back slashes () in URLs, yet IE supports the use of them.

    This was causing problems with a certain website I was making because the programmer had linked to everything with back slashes, and ofcourse the links didn’t work in Firefox.

    Can you please rectify this problem so people don’t assume it’s ok to use backslashes for their websites?

  41. Anonymous says:

    "Can you please rectify this problem so people don’t assume it’s ok to use backslashes for their websites?"

    I completely disagree. There is an old rule of programming when implementing specifications, be conservative in what you send, and liberal in what you accept. I believe IE is following that rule. I’d much rather bad code work in IE than not work because of standards conformance. IE is correct probably 99% of the time when it assumes the user meant to use a /, so why add needless difficulty? Instead, I’d be asking the Firefox people to add this feature!

  42. Anonymous says:

    So, will the classes controlling CURL’s be added to the .NET Framework?

  43. Anonymous says:


    I believe that’s the sort of attitude that makes IE such a pain for designers and developers today.

    There would be no need for rules and standards if they were just ignored all the time. By ignoring specifations you’re just making things more confusing; because how would you know if what you’re doing is correct?

    I would rather have code that doesn’t work at all rather than code that sometimes works. If something didn’t work at all, at least you could fix it before it becomes a habit.

    If a person repeatedly pronounced your name incorrectly would you not correct them?

    Specifations are there for a reason, follow them!

  44. Anonymous says:

    Could you make no limitation to URL length. Because URL length limitation to 2048 characters my Website is only compatible with Firefox. Thanks.

  45. Anonymous says:

    this is a really welcome enhancement. Link: IEBlog : URLs in Internet Explorer 7. Internet Explorer 7 includes a new URL handling architecture known internally as CURI. The new optimized URI functions provide more secure and consistent parsing of URIs

  46. Anonymous says:

    ‘I’m not quite ready to talk about IE7’s support for International Domain Names (IDN) yet’

    whats soo secret??

    (and why wasn’t there support in first beta)

  47. Anonymous says:

    <<<Could you make no limitation to URL length. Because URL length limitation to 2048 characters my Website is only compatible with Firefox.>>>

    10 billion webpages get along just fine with URLs under 2048 characters. The RFC calls for 1024. What the heck are you doing? URLs this long are terrible for performance.

    <<<There is an old rule of programming when implementing specifications, be conservative in what you send, and liberal in what you accept>>>

    Alas, that’s from the good old days, back before security bugs took advantage of liberal interpretations. IE should lock this down.

  48. Anonymous says:

    This is related to the post titled "fragment portion of URI and IE7 history"

    While you are at it, there are some other bugs related to the fragment portion of the url – namely adding a new fragment (hash) when there are none on the page, doesn’t create a history entry (I’m not sure if it should or not, but Netscape and Firefox both do), and when it changes, the change isn’t reflected in the location.hash property.

    While you are at it, if you could add an event to fire when the fragment (hash) changes, that would really be helpful to AJAX/Flash developers – even if it is non-standard (you could always submit it to some freindly standards body).

    And really pushing it, maybe you could add an event (ontarget) for items that are targeted by the new fragment (hash) that fires when the element gets targeted – it would be similar to how the element gets it’s style updated by the :target selector (if you plan to add that).

  49. Anonymous says:

    >> All IE7 is a knock-off version of FireFox, Netscape (owner of Mozilla, which created FireFox) has always been a better internet Browser.

    Firefox is a knock of Opera who has had tabbed browsing, popup blocking, css compliance, skinned browsing, search bar, abilty to turn off styles, etc. etc. etc. for years. Long before Firefox even existed. Firefox has copied Opera is so many ways it’s rediculous. So, stop harping on Microsoft for copying Firefox because Firefox is only and Opera wannabe. By the way incorporating a feature that is not currently in your program to make it better, even though a compeditor has already done that, is not a bod thing. It shows you are keeping up with the times. Should we harang Microsoft because they are bettering their css support, saying "Microsoft is adding to their css … they’re copying Firefox’s css support." It would be ludicrous to say that, and so is harping on Microsoft because they are adding tabbed browsing. Firefox didn’t invent it and it isn’t the best browser out there. Get over it.

  50. Anonymous says:

    "codemastr: But then when to tell if I actually means https://blah.com:81&quot;

    You’re right. However, when I just type in "blah.com" it defaults to http. I didn’t specify a WKP, it just assumes I want http. I think that should always be the case. Unless I specify a WKP or explicitely specify a protocol, it should default to http.

    Actually, to make it even better and to address both mine and M’s requests, what about making it configurable? IE apparently has some rules to determine "is this ftp?" "is this http?" what about making them user configurable. It could be like an Outlook rule.

    Where the PORT is 81 use HTTP

    Where the HOSTNAME begins with ftpsearch use HTTP

    That’d be pretty cool if you ask me.

  51. Anonymous says:

    Why switching to Firefox is a good idea.

    New Zero-Day IE Bug Can Give Attackers Control

    By Gregg Keizer

    Courtesy of TechWeb News

    While an official patch isn’t available from Microsoft — making this a so-called "zero-day" exploit — several workarounds can be applied by users or administrators, said the ISC. The kill bit for the ActiveX component could be set, the .dll could be removed (although that, warned the ISC, might break some applications), or users could switch to another browser, like Mozilla’s Firefox, which doesn’t use ActiveX.


  52. Anonymous says:

    Cheong: Running HTTPS on port other than 443 isn’t a good thing, because you can’t connect there via proxy.

  53. Anonymous says:

    codemastr: But then when to tell if I actually means https://blah.com:81

    I think it’s right to assume protocols only on well known ports.

  54. Anonymous says:

    I noticed with IE7’s new history handling, using Back and Forward on fragment links no longer works.

    Clicking a fragment link in a page no longer adds an item to the history, breaking that functionality.

    Is it planned to re-add history for fragment links?

  55. Anonymous says:

    It is encouraging to see a mention of RFC 3986 (a.k.a. STD 66 – it is the first URI spec to reach full IETF Internet Standard status!). Conformance with the resolution and normalization rules of this spec will be very welcome.

    On the W3C URI Interest Group mailing list, we’ve had several abortive attempts to settle on a new ‘file:’ URI spec. On the list I’ve occasionally mentioned and hoped to get some input and feedback from Microsoft regarding issues related to this — such as how UNC paths are mapped to and from ‘file:’ URIs (and your conventions & caveats re: ‘file:’ URIs in general); and what kind of URI normalization is performed by the Address Bar widget in Windows Explorer and Internet Explorer (and where the line is between what is done there and what is done in the resolver; the widget is lenient about what it accepts, and sometimes rewrites what you enter in it; what principles guide this normalization?).

    A couple of MS folks do seem to be on the list (Alun Jones, Michel Suignard) but they remained focused on other issues. If possible, could anyone with an inside track at MS help us produce a ‘file:’ spec that reflects best current practice, if not also strives to provide better guiding principles for future implementations? Thanks

  56. Anonymous says:

    …Is there going to be anything done about the way IE steals focus from the address bar upon loading the user’s home page?

    If you open IE, then start typing into the address bar, IE will suddenly steal focus, replace your typing with the URL of your home page, or, sometimes, just jump the cursor to the beginning of the line, leaving you typing URLs that come out as


    In my opinion, the very fact that the address bar has focus and has had recent typing activity means that IE has no business tinkering with the control focus or the contents of the address bar.

    It’s more than a little irritating.

  57. Anonymous says:

    Dear mr. Alberto, thank you for calling me and many other readers here very very experienced and very very sophisticated. I feel honored.

    But please, you too can educate yourself. Simply look at microsofts list of bugfixes they are now going to release with IE7 (http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx) for confirmation and learn more about its deeper, current mysteries at http://www.positioniseverything.net/ie-primer.html and http://www.satzansatz.de/cssd/onhavinglayout.html.

    Read up and come and join us at our side of the fence 😉

  58. Jie Ren says:

    An encapsulated URL class that controls all aspects of URL can also help the server side URL parsing. I recall there are several URL parsing related vulnerabilities with older IIS, some are national language related.

    I am wondering what would be the next architectural change in URL handlers. Previous comments request support for data: URL. I am actually wondering whether javascript: URL would receive a different treatment, since this is inherently more dangerous than just showing some text or image. I am guessing maybe a URL scheme based policy can help, and probably the proper URL permissions/origins can be propagated along all code path.

    From a secure software architecture viewpoint, the CURL is a great improvement. Good job!

  59. Anonymous says:

    EricLaw, even given unlikely ../ directories in absolute addresses, it is still not infinite if there is a practical limit to the length of URLs.

  60. Anonymous says:

    1. ChrisH: No need to convert your relative hyperlinks to absolute; the efficiency savings would be miniscule, you’d have to transfer more bytes over the wire, and it would cause problems if you ever wanted to change your root domain.

    2. Brianiac: Actually, the equivalent set is infinite. http://www.example.com/1/../ == http://www.example.com/2/../, etc.

    3. Peter: You can turn off sounds using the Control Panel.

  61. Anonymous says:

    Alberto, here is an article that will bring you up to speed:


  62. Anonymous says:

    Guys, could you add a setting to turn off SOUNDS in IE? It drives me insane that for the last however many years I have to listen to pages loading!!!

  63. Anonymous says:

    so, is CURI the reason why Navigate() now fails

    on IWebBrowser2?

    i’m guessing i’ll have to put the url inside

    a CURI object.

    in order to prepare for IE7,

    us developers will need some details on CURI.

  64. Anonymous says:

    Is it a feature of IE6 that relative https: links don’t work i.e. https:newpage.htm won’t be cracked at all?

  65. Its been a while since my last post here. I guess Beta 2 work has been taking most of my time. But I

  66. JD on EP says:

    IE7 js: URL problem? I messed up, and now I’m trying to fix it, and am also seeking anecdotal info you may have on whether Microsoft Internet Explorer 7 changes the way that "javascript:" URLs are handled when requested in ActiveX Controls. In an old

  67. IEBlog says:

    One of the benefits of creating a new URI parsing API for IE7 was that we were able to more easily add

  68. A friend just showed me this brilliant Heartburn and Acid reflux website that gives you great tips

  69. If you’re looking cure your acid reflux, then this blog has some excellent tips!

Skip to main content