Lots of noise about user agent strings

On Jun 1, 12:20 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:

On May 29, 4:22 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:



If you were a system administrator and you wanted to send gzipped
JavaScript files to save bandwidth, how would you determine which
browsers could accept gzipped files and which could not?

Looking at the Accept-Encoding header.

In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)
With a reliable stats proving the point of view, please ;-)

On Jun 1, 10:29*am, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Jun 1, 12:20 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:

On May 29, 4:22 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

If you were a system administrator and you wanted to send gzipped
JavaScript files to save bandwidth, how would you determine which
browsers could accept gzipped files and which could not?

Looking at the Accept-Encoding header.

In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)
With a reliable stats proving the point of view, please ;-)

Fool the server in order to receive a .gz that you can't deal with ?
Why would you want to ?

--Jorge.

VK <schools_ring (AT) yahoo (DOT) com> writes:

In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)

Because users have, or have had, reason to fake the User-Agent string
(fake in the sens that it claims to be a user agent that the browser
is not in fact a version of), in order to receive usable content. They
have never had a reason to fake the accept-encoding string (fake in
the sense that it claims to accept an encoding that the browser does
not in fact understand), because there are no web sites where that
would give the client any advantage. By faking the accept-encoding,
they may get something they don't understand, i.e., the page might
stop working. There is no way it can make a broken page start working.

With a reliable stats proving the point of view, please ;-)

Nope. You find one page where faking the accept-encoding would help,
or any browser that by default claims to accept an encoding that it
doesn't understand, and I'd consider that there might be reason to not
trust it totally.

The accept-encoding header has, from the start, been meant as a way
for the browser to represent its exact capabilities to the server. The
servers have taken it as such. NO server has said "if you accept gz
compression, then you probably also accept arj compression, so I'll
just use that". That's the kind of faulty feature deduction that web
authors do based on the User Agent string, which was never officially
meant to specify capabilities (and even if it does, was used to exclude
those that were not recognized, which got us into this mess.).

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

On Jun 1, 1:59 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:

On Jun 1, 10:29 am, VK <schools_r... (AT) yahoo (DOT) com> wrote:



On Jun 1, 12:20 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:

On May 29, 4:22 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

If you were a system administrator and you wanted to send gzipped
JavaScript files to save bandwidth, how would you determine which
browsers could accept gzipped files and which could not?

Looking at the Accept-Encoding header.

In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)
With a reliable stats proving the point of view, please ;-)

Fool the server in order to receive a .gz that you can't deal with ?
Why would you want to ?

And why anyone would want to fool the server in order to receive a
content the browser cannot deal with?

On Jun 1, 2:16 pm, Lasse Reichstein Nielsen <l... (AT) hotpop (DOT) com> wrote:

VK <schools_r... (AT) yahoo (DOT) com> writes:
In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)

Because users have, or have had, reason to fake the User-Agent string

Correction: not users, but some browser producers. The only other
cases I am aware of are experienced programming involved users
removing some data from the distributer section of User-Agent string
in IE. This section is at the rightmost position of the string and was
originally intended to put the name of the computer seller with
Windows and IE pre-installed - so like an extra bonus to IE supporters
at IE3/IE4 times. Obviously Microsoft doesn't push this promo option
anymore but the relevant registry field still inherited - and some
programs once had a bad habit to add their own marker in there for the
relevant software sniffing and usage stats collection. This part of
the User-Agent string is always welcome to be checked and killed if
needed. Many PC maintenance programs do provide this option so users
do not have to dig in the registry manually.

(fake in the sens that it claims to be a user agent that the browser
is not in fact a version of), in order to receive usable content. They
have never had a reason to fake the accept-encoding string (fake in
the sense that it claims to accept an encoding that the browser does
not in fact understand), because there are no web sites where that
would give the client any advantage. By faking the accept-encoding,
they may get something they don't understand, i.e., the page might
stop working. There is no way it can make a broken page start working.

With a reliable stats proving the point of view, please ;-)

Nope. You find one page where faking the accept-encoding would help,
or any browser that by default claims to accept an encoding that it
doesn't understand, and I'd consider that there might be reason to not
trust it totally.

And do we have a site where User-Agent spoofing would help? Like with
this string welcome, with this - go away? I mean being reasonable so
on a browser no more than 6-7 years old?

The accept-encoding header has, from the start, been meant as a way
for the browser to represent its exact capabilities to the server. The
servers have taken it as such. NO server has said "if you accept gz
compression, then you probably also accept arj compression, so I'll
just use that". That's the kind of faulty feature deduction that web
authors do based on the User Agent string, which was never officially
meant to specify capabilities (and even if it does, was used to exclude
those that were not recognized, which got us into this mess.).

The Browser Wars was the fight of two: nobody cared of some 3rd or
4th. It is not fair to blame on developers that they didn't account
some possible neutral 3rd parties that will come someday from
somewhere.
It is not an argument, just a side comment.

On Jun 1, 7:28*pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Jun 1, 1:59 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:



On Jun 1, 10:29 am, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Jun 1, 12:20 pm, Jorge <jo... (AT) jorgechamorro (DOT) com> wrote:

On May 29, 4:22 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

If you were a system administrator and you wanted to send gzipped
JavaScript files to save bandwidth, how would you determine which
browsers could accept gzipped files and which could not?

Looking at the Accept-Encoding header.

In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)
With a reliable stats proving the point of view, please ;-)

Fool the server in order to receive a .gz that you can't deal with ?
Why would you want to ?

And why anyone would want to fool the server in order to receive a
content the browser cannot deal with?

Nope, it's :

Engañar al servidor para recibir un fichero .gz con el que no puedes
hacer nada ?
Por que ibas a querer hacer eso ?

8¬)

Peter Michaux wrote:

On May 29, 4:19 pm, Richard Cornford wrote:
Peter Michaux wrote:
snip
If you were a system administrator and you wanted to send
gzipped JavaScript files to save bandwidth, how would you
determine which browsers could accept gzipped files and
which could not?

The HTTP Accept-Encoding header sent with the request would
seem like the obvious place to start (as that is precisely
what it is for).

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

IE 6 absolutely can accept gzip encoding, else that would have been
spotted long ago and be very well known by now.

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? Such as the precise size of the (compressed
or uncompressed) files that are supposed to be a problem, a Microsoft KB
article about it, a test case created by someone who's analytical skills
run to real cause and effect identification?

Beyond my normal cynicism, one of the reasons that I suspect this is BS
is that at work we have a QA department that delights in trying to break
our web applications (which is, after all, their job) and one of the
ways they try to do that is by overwhelming the browser with huge
downloads. The HTTPS test servers are set-up to server gziped content
when they think they can and IE 6 is certainly is the test set of
browser used so not having seen any evidence of this being a problem
suggest that it is not (or the problematic files size is so very large
that there is no real issue).

This leads to the use of the user agent string.
snip

But you only have to see that other browsers send default UA headers
that are indistinguishable from that of IE 6 to know that would be a
poor approach. If you had to make an assumption based on a request
header I would probably pick on IE's unusual Accept header. How many
other browsers would be willing to accept the set of Microsoft specific
formats that IE says it would prefer (say Word and Access documents)?
And even if some other browser said it could handle that content would
those types come out with the same relative q values as in IE 6's Accept
header? That doesn't entirely solve the problem because IE's Accept
headers can be modified, but it is better than looking at something that
is known to be deliberately spoofed by other browsers.

Richard.

VK wrote:

On Jun 1, 12:20 pm, Jorge wrote:
On May 29, 4:22 am, Peter Michaux wrote:

If you were a system administrator and you wanted to send
gzipped JavaScript files to save bandwidth, how would you
determine which browsers could accept gzipped files and
which could not?

Looking at the Accept-Encoding header.

In the context of the discussion I dare to question what
principal difference one sees between altering over say
(Gecko) about:config User-Agent string and altering
network.http.accept-encoding string? If one doesn't have
a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)

Who is proposing not trussing the User Agent header? The HTTP
specification defines it as an arbitrary sequence of characters that
does not even need to be consistent over time, and so as being something
that should not be treated as a source of information. And the proposal
being made here is to trust it to be precisely what it is defined as
being; not a source of information.

With a reliable stats proving the point of view, please ;-)

"Stats" are not capable of "proving" anything.

Richard.

VK wrote:

On Jun 1, 2:16 pm, Lasse Reichstein Nielsen <l... (AT) hotpop (DOT) com> wrote:
VK <schools_r... (AT) yahoo (DOT) com> writes:
In the context of the discussion I dare to question what principal
difference one sees between altering over say (Gecko) about:config
User-Agent string and altering network.http.accept-encoding string? If
one doesn't have a trust to one chunk of info send by agent, why so
much trust to another chunk sent in the same request? ;-)

The premises of your argument are false. The problem with user-agent
feature detection has never been that the user-agent string is
"untrustworthy"; there is no trust relationship between the user agent
and the server, so that attribute does not apply. User-agent feature
detection is a broken mechanism because it makes incorrect inferences,
especially false negatives that restrict UAs from receiving content
they're perfectly capable of handling.

Because users have, or have had, reason to fake the User-Agent string

Correction: not users, but some browser producers.

A bogus dichotomy. The user agent is an agent of the user.

User-agent values often are set by the user; it doesn't matter what
tool enables them to do so.

The only other
cases I am aware of are experienced programming involved users
removing some data from the distributer section of User-Agent string
in IE.

It is remotely possible that your experience does not cover the entire
set of applicable cases.

And do we have a site where User-Agent spoofing would help? Like with
this string welcome, with this - go away? I mean being reasonable so
on a browser no more than 6-7 years old?

GIYF. A trivial search turned up complaints about [1], for example.
Look at the Javascript used by that page, particularly the computation
of the variables is_ie and is_nav, and how they're used in functions
like displayAll().

The Browser Wars was the fight of two: nobody cared of some 3rd or
4th.

Except the people who did, of course. And the people who cared about
standards.

It is not fair to blame on developers that they didn't account
some possible neutral 3rd parties that will come someday from
somewhere.

Oh yes it is. That's the whole point of standards and
interoperability, and those have always been explicit goals for the
web, just like most other Internet applications.

[1] http://www.trader.ca/search/default....goryid=1&CAT=1

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

On Jun 1, 10:19 pm, "Richard Cornford" <Rich... (AT) litotes (DOT) demon.co.uk>
wrote:

Peter Michaux wrote:
On May 29, 4:19 pm, Richard Cornford wrote:
Peter Michaux wrote:
snip
If you were a system administrator and you wanted to send
gzipped JavaScript files to save bandwidth, how would you
determine which browsers could accept gzipped files and
which could not?

The HTTP Accept-Encoding header sent with the request would
seem like the obvious place to start (as that is precisely
what it is for).

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

IE 6 absolutely can accept gzip encoding, else that would have been
spotted long ago and be very well known by now.

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? Such as the precise size of the (compressed
or uncompressed) files that are supposed to be a problem, a Microsoft KB
article about it, a test case created by someone who's analytical skills
run to real cause and effect identification?

Beyond my normal cynicism, one of the reasons that I suspect this is BS
is that at work we have a QA department that delights in trying to break
our web applications (which is, after all, their job) and one of the
ways they try to do that is by overwhelming the browser with huge
downloads. The HTTPS test servers are set-up to server gziped content
when they think they can and IE 6 is certainly is the test set of
browser used so not having seen any evidence of this being a problem
suggest that it is not (or the problematic files size is so very large
that there is no real issue).

As a devil advocate I would suggest to your QA department to test IE6
SP1 w/o Q837251 patch installed ;-)
That is in reference to http://support.microsoft.com/kb/837251
But if they come back victorious you may point out that users not
updating their IE or Windows for a year and half do deserve every bit
of troubles they are getting as the result.