Peter said:
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.getAttribute ) {
// 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.body.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(function(){
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(function(){
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.
