Lots of noise about user agent strings

[VK]

Re: Lots of noise about user agent strings

On Jun 15, 8:11 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

Peter Michaux wrote:

On Jun 1, 11:48 am, VK wrote:

On Jun 1, 10:19 pm, Richard Cornford wrote:
>Peter Michaux wrote:
>>On May 29, 4:19 pm, Richard Cornford wrote:
>>>Peter Michaux wrote:

<snip>

>>I believe that the issue is that IE6 claims it can accept
>>gzip but in actual fact it cannot due to a decompression bug.

<snip>

>>This bug may only apply to files over a certain size.

>

>Are we in the realm of rumour and folk-law or are there
>demonstrable facts behind this assertion? ...

<snip>

That is in reference tohttp://support.microso ft.com/kb/837251

<snip>

This must have been it. It is good to know the issue is gone
in new or updated browsers but the general problem still exists.

>
The Microsoft KB article asserts that the issue was introduced in a
security update for IE, and then fixed in a patch, so the issue is with
IE installations that have had some updates but are not up to date, or
non-updated installations of versions released between the introduction
of the security update and the issuing of the patch. Microsoft don't
seem very keen to let the reader know which security update introduced
the issue (so we can know the length of the interval between its release
and the patch that fixed its bugs) or the size of the downloads in
question.
>

The server cannot feature test the client directly (at least not
easily) and does need to rely on the strings it is sent.

>
But the Accept Encoding string not the User Agent string.

and I keep asking within this thread why one request header has to be
particularly mistrusted and some other request header has to be
particularly trusted? - given the same amount of work involved to
alter or to spoof either one client-side?

the second question everyone failed to answer so far is why User-Agent
spoofing has to be considered as a decisive reason to not use User-
Agent: but client caps spoofing is considered as not a big deal. In
the realm of practical programming the situation is right opposite.
compare for instance the listed procedures to alter User-Agent for say
Gecko or IE and now with a code like:
window.ActiveXO bject = new Function;
or
window.opera = new Object;


(shudder + surprised look on my face)

[Peter Michaux]

Re: Lots of noise about user agent strings

On Jun 15, 9:11 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

Peter Michaux wrote:

On Jun 1, 11:48 am, VK wrote:

On Jun 1, 10:19 pm, Richard Cornford wrote:
>Peter Michaux wrote:
>>On May 29, 4:19 pm, Richard Cornford wrote:
>>>Peter Michaux wrote:

<snip>

>>I believe that the issue is that IE6 claims it can accept
>>gzip but in actual fact it cannot due to a decompression bug.

<snip>

>>This bug may only apply to files over a certain size.

>

>Are we in the realm of rumour and folk-law or are there
>demonstrable facts behind this assertion? ...

<snip>

That is in reference tohttp://support.microso ft.com/kb/837251

<snip>

This must have been it. It is good to know the issue is gone
in new or updated browsers but the general problem still exists.

>
The Microsoft KB article asserts that the issue was introduced in a
security update for IE, and then fixed in a patch, so the issue is with
IE installations that have had some updates but are not up to date, or
non-updated installations of versions released between the introduction
of the security update and the issuing of the patch. Microsoft don't
seem very keen to let the reader know which security update introduced
the issue (so we can know the length of the interval between its release
and the patch that fixed its bugs) or the size of the downloads in
question.

So during IE's Accept Encoding lying period (or perhaps even now since
there may still be browsers out there partly updated), would you
simply not send gzipped content at all because the Accept Encoding is
not reliable? Or would you use the User Agent string to save the
servers potentially quite a lot of their load? Or is there something
better to be done?

Peter

[Thomas 'PointedEars' Lahn]

Re: Lots of noise about user agent strings

Peter Michaux wrote:

"Richard Cornford" wrote:

>Peter Michaux wrote:

>>On Jun 1, 11:48 am, VK wrote:
>>>[http://support.microsoft.com/kb/837251]
>>This must have been it. It is good to know the issue is gone
>>in new or updated browsers but the general problem still exists.

>The Microsoft KB article asserts that the issue was introduced in a
>security update for IE, and then fixed in a patch, so the issue is with
>IE installations that have had some updates but are not up to date, or
>non-updated installations of versions released between the introduction
>of the security update and the issuing of the patch. [...]

>
So during IE's Accept Encoding lying period (or perhaps even now since
there may still be browsers out there partly updated), would you
simply not send gzipped content at all because the Accept Encoding is
not reliable?

Date Published: 5/5/2004

Or would you use the User Agent string to save the servers potentially
quite a lot of their load?

The User-Agent header value does not need to show the UA's patch level.

Or is there something better to be done?

Not to use IEeek.


PointedEars

[Peter Michaux]

Re: Lots of noise about user agent strings

On Jun 18, 12:41 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

Peter Michaux wrote:

"Richard Cornford" wrote:

Peter Michaux wrote:
>On Jun 1, 11:48 am, VK wrote:
>>[http://support.microsoft.com/kb/837251]
>This must have been it. It is good to know the issue is gone
>in new or updated browsers but the general problem still exists.
The Microsoft KB article asserts that the issue was introduced in a
security update for IE, and then fixed in a patch, so the issue is with
IE installations that have had some updates but are not up to date, or
non-updated installations of versions released between the introduction
of the security update and the issuing of the patch. [...]

>

So during IE's Accept Encoding lying period (or perhaps even now since
there may still be browsers out there partly updated), would you
simply not send gzipped content at all because the Accept Encoding is
not reliable?

>
Date Published: 5/5/2004
>

Or would you use the User Agent string to save the servers potentially
quite a lot of their load?

>
The User-Agent header value does not need to show the UA's patch level.

I believe that the general technique just sends non-gzipped to all
user agents claiming to be IE less than version seven. Given that
other browsers now have a large share of the market the technique
could still lead to a big savings.

Peter

[Thomas 'PointedEars' Lahn]

Re: Lots of noise about user agent strings

Peter Michaux wrote:

Thomas 'PointedEars' Lahn wrote:

>Peter Michaux wrote:

>>"Richard Cornford" wrote:
>>>Peter Michaux wrote:
>>>>On Jun 1, 11:48 am, VK wrote:
>>>>>[http://support.microsoft.com/kb/837251]
>>>>This must have been it. It is good to know the issue is gone
>>>>in new or updated browsers but the general problem still exists.
>>>The Microsoft KB article asserts that the issue was introduced in a
>>>security update for IE, and then fixed in a patch, so the issue is with
>>>IE installations that have had some updates but are not up to date, or
>>>non-updated installations of versions released between the introduction
>>>of the security update and the issuing of the patch. [...]
>>So during IE's Accept Encoding lying period (or perhaps even now since
>>there may still be browsers out there partly updated), would you
>>simply not send gzipped content at all because the Accept Encoding is
>>not reliable?

>Date Published: 5/5/2004
>>

>>Or would you use the User Agent string to save the servers potentially
>>quite a lot of their load?

>The User-Agent header value does not need to show the UA's patch level.

>
I believe that the general technique just sends non-gzipped to all
user agents claiming to be IE less than version seven. Given that
other browsers now have a large share of the market the technique
could still lead to a big savings.

Given that this patch was released more than four years ago, you would
support faulty software. I would consider this a Bad Idea. I don't see
any savings here.


PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16

[Richard Cornford]

Re: Lots of noise about user agent strings

Peter Michaux wrote:

On Jun 15, 9:11 am, Richard Cornford wrote:

>Peter Michaux wrote:

>>On Jun 1, 11:48 am, VK wrote:
>>>On Jun 1, 10:19 pm, Richard Cornford wrote:
>>>>Peter Michaux wrote:
>>>>>On May 29, 4:19 pm, Richard Cornford wrote:
>>>>>>Peter Michaux wrote:

><snip>

>>>>>I believe that the issue is that IE6 claims it can accept
>>>>>gzip but in actual fact it cannot due to a decompression
>>>>>bug.

><snip>

>>>>>This bug may only apply to files over a certain size.

>>

>>>>Are we in the realm of rumour and folk-law or are there
>>>>demonstrabl e facts behind this assertion? ...

><snip>

>>>That is in reference tohttp://support.microso ft.com/kb/837251

><snip>

>>This must have been it. It is good to know the issue is gone
>>in new or updated browsers but the general problem still exists.

>>
>The Microsoft KB article asserts that the issue was introduced in
>a security update for IE, and then fixed in a patch, so the issue
>is with IE installations that have had some updates but are not
>up to date, or non-updated installations of versions released
>between the introduction of the security update and the issuing
>of the patch. Microsoft don't seem very keen to let the reader
>know which security update introduced the issue (so we can know
>the length of the interval between its release and the patch
>that fixed its bugs) or the size of the downloads in question.

>
So during IE's Accept Encoding lying period (or perhaps even
now since there may still be browsers out there partly updated),
would you simply not send gzipped content at all because the
Accept Encoding is not reliable?

As with anything else, the issue needs to be pinned down before any
reaction makes sense. We still do not know the nature of the cut-off
point. It is asserted that the effected IE browsers will not properly
handle zipped material above a certain size, but is that size hundreds
of kilobytes, megabytes, tens of megabytes, hundreds of megabytes or
gigabytes?

To start with, once the size is known it is possible to disregard the
issue entirely whenever the server is sending anything smaller than that
limit. And then it is possible for the context to rule that the 'issue'
is moot; for example, in the event that you have a web site were you can
know that all the content that can be served is within the known limit.

This is why I am so cynical about such reports (or at least one of the
reasons[1]), because the true nature of issue is so important to the
handling of the issue that any repost of an issue without the relevant
technical details suggests more a failure of analysis than any real
issue.

Or would you use the User Agent string to save the servers
potentially quite a lot of their load?

If we assume that this size limits is not small, indeed is considerably
larger than anything that would normally be included in/imported by a
web page (which seems reasonable as Microsoft's QA is unlikely to have
missed this if the limit was that small) then the bulk of the load for
the vast majority of servers is not relevant for this issue at all. So
for the small minority of situation where the thing being delivered is
sufficiently large for this issue to be relevant there are lots of
possibilities. Looking at the UA string would be a long way down the
list of possibilities.

Or is there something
better to be done?

The best thing to do is to understand the true nature of the issue, and
the real context in which you are trying to address that issue.

[1] There reasons for being so cynical about such reports include the
amount of bullshit put about by people who should know better, and the
degree to which fundamentally faulty analysis is used to draw
concussions and then goes unnoticed by people who swallow those
conclusions.

To illustrate the former:-

<quote
cite="http://ejohn.org/blog/future-proofing-javascript-libraries/">

Additionally, in Internet Explorer, doing object detection checks can,
sometimes, cause actual function executions to occur. For example:

if ( elem.getAttribu te ) {
// will die in Internet Explorer
}
That line will cause problems as Internet Explorer attempts to execute
the getAttribute function with no arguments (which is invalid). ... "
</quote>

- is just an obviously false assertion. It is easy to demonstrate as
being false with simple examples such as:-

<html>
<head>
<title></title>
</head>
<body>
<script type="text/javascript">
window.onload = function(){
if(document.bod y.getAttribute) {
alert('Code is fine!');
}
};
</script>
</body>
</html>

- load that into IE and if the above statement were true you would not
be seeing the alert. And it is not even a statement that may have been
true at some time in the past and later fixed in an IE update, because
feature detection has been in regular use for a decade or more and has
included feature testing of getAttribute methods on elements for all of
that time, and yet this supposed issue has never been raised on this
group (which has approximately 30,000 posts/year over that period).

(There was an issue that this may be a "Chinese whispers" representation
of, where, for a short period (until fixed by an update), attempting to
read Element node interface properties form an attribute node would
cause IE 6 to crash and so reading - getAttribute - on an attribute node
would be an example of that (but that is crashing the browser not
erroneously executing the method with no argument). But that was never
an issue in cross browser scripting because it simply makes no sense to
attempt to use - get/setAttribute - on an attribute node and so nobody
attempted to feature detect for the existence of those method on that
object.)

An illustration of faulty analysis can be found on:-

<URL: http://ejohn.org/blog/most-bizarre-ie-quirk/ >

- where the code:-

setInterval(fun ction(){
alert("hello!") ;
}, -1);

is used to examine some unique IE behaviour when - setTimeout - is given
a millisecond argument of -1. The conclusion drawn is that "The callback
function will be executed every time the user left clicks the mouse,
anywhere in the document.". And then the subsequent discussion goes on
to consider the relationship between this and onclick events (which
would come first, etc.)

That conclusions in utterly false and stems from a significant but
obvious fault in the testing method used to perform the analysis. The
fault is in using - alert - to signal the calling of the callback
function and then using that in conjunction with conclusions about mouse
interactions. The problem being that - alert - blocks javascript
execution and transfers focus to the button on the alert box, both of
which have a huge impact on interactive behaviour in web browsers.

Change the test code to:-

<script type="text/javascript">
var count = 0;
setInterval(fun ction(){
window.status = (++count);
}, -1);
</script>

-, so that the execution of the call-back function is signalled by the
incrementing of a number displayed in the window's status bare, and a
totally different impression of what is happening is revealed. That is,
the call-back function appears to start firing as soon as the mouse
button is depressed (so onmousedown not onclick) and the function is
called repeatedly until the button is released (or, apparently, a drag
event starts).

For me (so dependent on the rate at which my finger moved, the OS/OS
settings and probably the CPU speed on this computer) the counter has
reached 5 by the time I have completed a normal mouse click. Thus if the
call-back function is executed five times during a click the call-back
function is _not_ "executed every time the user left clicks the mouse".

It does not take much experience (or even much thinking about it) to see
that alert is of limited usefulness when testing mouse interactions, but
still there it is, along with resulting conclusions that are divergent
from reality.

Richard.