Lots of noise about user agent strings

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 to http://support.microsoft.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.

Richard.

On Jun 15, 8:11 pm, "Richard Cornford" <Rich... (AT) litotes (DOT) 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.microsoft.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.ActiveXObject = new Function;
or
window.opera = new Object;


(shudder + surprised look on my face)

On Jun 16, 2:37 am, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Jun 15, 8:11 pm, "Richard Cornford" <Rich... (AT) litotes (DOT) demon.co.uk
wrote:
Peter Michaux wrote:
[...]
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?

That has been answered. In brief, UA strings are known to be
falsified in order to disguise browsers and platforms. The motivation
is to overcome erroneous discrimiation based on the UA string and make
available content that might otherwise have been witheld.

No similar behaviour is widespread in regard to the HTTP request-
header Accept-Encoding field because there is no motivation to do it.
Falsifing such information will almost certainly lead to errors and
failures, making information unavailable that would otherwise have
been available.


--
Rob

On Jun 15, 9:11 am, "Richard Cornford" <Rich... (AT) litotes (DOT) 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.microsoft.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

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 bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16