Andrea:

\r\n

I'm sure I've misunderstood a thing or two from time to time so just to\r\ncheck I downloaded Opera 7 again this time on my home system.

\r\n\r\n

If you open it and go to File, Preferences and Network it says identify\r\nas MSIE 6.0 as the default you can choose other identities if you want\r\nthere must be some reason that the folks at Opera made this the default\r\nso I don't see why they're complaining about other settings.

\r\n

In the event you've failed to grasp the distinction, it's not\r\nwhat the menu option says, its what the emitted user-agent\r\nstring is. To properly determine this, you need to aim your\r\nbrowser(s) at a known webserver and observe the logged agent strings.\r\nIf you can distinguish Opera from MSIE, then so can Microsoft (or anyone\r\nelse).

The actual string values sent by various browsers (Opera, MSIE,\r\nNetscape) are given here:

\r\n[link|http://people.opera.com/howcome/2003/2/msn/|http://people.opera.com/howcome/2003/2/msn/]\r\n

...and in the event you've failed to grasp the concept of hyperlinks\r\nand reading the article, the are:

\r\n
• Opera 7.0: Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.0 [en]
\r\n\r\n
• MSIE 6.0: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
\r\n\r\n
• Netscape 7.01: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
\r\n\r\n

Note that the Opera string reports itself as MSIE 6.0, which would\r\nmatch in any webserver check for compatibility with MSIE. The\r\nonly situations in which you'd look for the Opera string are if you're\r\ninterested in logging other user-agent types, or if you explicitly want\r\nto deny access to Opera.

If you want to test results without loading verious browsers, simply\r\nuse the wget recipies given on the site above with the\r\nspecified user-agent specifications. The resulting page pulls\r\nare different, and the stylesheet returned for Opera breaks both Opera\r\nAND MSIE.

Note to that all three browsers refer to themselves first as\r\n"Mozilla". This harkens back to the day when Netscape ruled the browser\r\nroost, and many sites declined to serve pages to other browser types\r\n(sad commentary on Netscape, FWIW, and ample demonstration that\r\nMicrosoft isn't alone in pulling bone-headed idiocy such as this).

It's gross abuse of the user-agent string which leads me to set my\r\nown to the following:

\r\nStop fucking obsessing over user-agent and code to W3C standards already.\r\n

I encourage others to do likewise. What I'm running is of no concern\r\nto the site serving me pages.

See also: [link|http://twiki.iwethey.org/twiki/bin/view/Main/UserAgentString|TWikIWeThey:UserAgentString]

Here's the deal.

You can exercise your right to request standards now. Or find\r\nyourself locked into "solutions" which solve more of your vendors'\r\nproblems than your own.

Nobody ever said being principled doesn't incur some level of pain.\r\nIt's generally an offset of current vs. future benefits. The path of\r\nleast resistance tends to have negative long-term consequences.

If you've got some compelling business app that requires a dedicated\r\nbrowser, you may make an exception. But note that you're doing so, and\r\ninform your vendor that you consider the requirement a negative\r\nstrike.

Two parallels:

\r\n
1. "Binary only" GNU/Linux kernel drivers. These were somewhat popular\r\nfor a time with HW manufacturers who didn't want to go fully open\r\nsource, but didn't want to miss the GNU/Linux bandwagon either. Their\r\ncompromise was binary drivers. The catch was that a given driver was\r\nrated for a limited set of kernel version(s). The inevitable conflict\r\nwas feature X supported in kernel n, and driver Y, only supported in\r\nkernel n + epsilon. The usual result: another hardware vendor was\r\nfound when at all possible. Binary-only drivers are frequently worse\r\nthan useless: they provide a false impression of support.
\r\n\r\n
2. Consider the logical outcome of accepting arbitrary browser\r\nrequirements: what's to make site A's requirements reasonable, but not\r\nsite B's? And if these requirements conflict? A well-known limitation\r\nof MSIE is that because it's "integrated" to the OS (actually: the user\r\nshell), a given system can only support one version of MSIE. With most\r\nalternatives, it's trivial to support multiple browser versions (I've\r\nhad systems with NS 3.01 - 7 installed for compatibility testing\r\npurposes). It's pretty easy to get into the situation where one site's\r\nrequirements conflict with another and a given computing platform lacks\r\nthe flexibility to accomodate the conflict. The business world is\r\ncurrently advocating standards-based web application design precisely\r\nfor this reason. You simply can't accomodate different browser\r\nrequirements from different vendors, clients, or partners.
\r\n

In short: while my own motivations for this action are principled,\r\nthe truth is that it's really the only pragmatic choice. User-agent\r\nbased discrimination is not tolerable. Best push back\r\nnow.