QUESTION: Can a function be set up as a constant in JS?
in [JavaScript]
|
Prev: how to get url of script
Next: question of logic?
From: David Mark on 30 Mar 2010 14:02 Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: > >> On 20/03/10 22:21, David Mark wrote: >>> Like hell they are. Server side sniffing is not in widespread use, >>> except by the most incompetent of server administrators (who should >>> really be digging ditches instead). >> I'd like to believe that, but the default Apache config file for SSL >> vhosts in Debian contains this passage: >> >> # SSL Protocol Adjustments: >> [...] >> # Notice: Most problems of broken clients are also related to the HTTP >> # keep-alive facility, so you usually additionally want to disable >> # keep-alive for those clients, too. Use variable "nokeepalive" for >> # this. Similarly, one has to force some clients to use HTTP/1.0 to >> # workaround their broken HTTP/1.1 implementation. Use variables >> # "downgrade-1.0" and "force-response-1.0" for this. >> BrowserMatch ".*MSIE.*" \ >> nokeepalive ssl-unclean-shutdown \ >> downgrade-1.0 force-response-1.0 >> >> Looks rather heavy handed... >> "Back to the '90s, Opera! Here's some HTTP/1.0 for you." > > It (/etc/apache2/sites-available/default-ssl) has been changed to > > | BrowserMatch "MSIE [2-6]" \ > | nokeepalive ssl-unclean-shutdown \ > | downgrade-1.0 force-response-1.0 > | # MSIE 7 and newer should be able to use keepalive > | BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown > > in apache2.2-common 2.2.15-2. > >> I'm not an expert on how well SSL is supported in legacy user agents, >> but feature testing a client isn't as easy on the server as it is in >> JavaScript - the request header's all you've got to work on. > > ACK > Can you elaborate on that ACK? I can't imagine you are advocating that a Web server should change gears based on the UA header. (?)
From: Stefan Weiss on 30 Mar 2010 20:00 On 31/03/10 01:11, Thomas 'PointedEars' Lahn wrote: >> Thomas 'PointedEars' Lahn wrote: >>> It (/etc/apache2/sites-available/default-ssl) has been changed to >>> >>> | BrowserMatch "MSIE [2-6]" \ >>> | nokeepalive ssl-unclean-shutdown \ >>> | downgrade-1.0 force-response-1.0 >>> | # MSIE 7 and newer should be able to use keepalive >>> | BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown >>> >>> in apache2.2-common 2.2.15-2. [...] > The expression above should be further refined, though, as there are > still too many false positives with it (Opera 5.02 to 8.0 for Windows > being a distinct possibility, for example). Or even more recent versions. In a collection of user agent strings (which is admittedly over a year old), I found Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en) Opera 9.51 That would definitively be a false positive, and it's very likely that newer Opera versions are also affected. My sympathy is somewhat limited, though... that's what you get for masquerading as Mozilla and MSIE, when you're neither. Anyway, the Apache BrowserMatch directive should be probably be refined to exclude Opera. I'll submit a patch if I can find the time. Does anybody know if there are Opera versions which _do_ have the same SSL problems as the old IEs? And finally, just for fun, when I grepped the user agent list for "opera", I stumbled across this gem: mozilla/3.0b5pre with grabage in ua is neither Opera/9.20 nor msie7.0 nor Safari or any other browser(it is not on any version of Windows nor NT 6.0 nor on a mac but on linux; U;language hidden (en, en-us, it, es, de, nl, fr, fi ???) hahahahahahahhaahh ) So much for trusting the UA string :) -- stefan
From: David Mark on 30 Mar 2010 20:45 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Stefan Weiss wrote: >>>> David Mark wrote: >>>>> Like hell they are. Server side sniffing is not in widespread use, >>>>> except by the most incompetent of server administrators (who should >>>>> really be digging ditches instead). >>>> I'd like to believe that, but the default Apache config file for SSL >>>> vhosts in Debian contains this passage: >>>> >>>> # SSL Protocol Adjustments: >>>> [...] >>>> # Notice: Most problems of broken clients are also related to the HTTP >>>> # keep-alive facility, so you usually additionally want to disable >>>> # keep-alive for those clients, too. Use variable "nokeepalive" for >>>> # this. Similarly, one has to force some clients to use HTTP/1.0 to >>>> # workaround their broken HTTP/1.1 implementation. Use variables >>>> # "downgrade-1.0" and "force-response-1.0" for this. >>>> BrowserMatch ".*MSIE.*" \ >>>> nokeepalive ssl-unclean-shutdown \ >>>> downgrade-1.0 force-response-1.0 >>>> >>>> Looks rather heavy handed... >>>> "Back to the '90s, Opera! Here's some HTTP/1.0 for you." >>> It (/etc/apache2/sites-available/default-ssl) has been changed to >>> >>> | BrowserMatch "MSIE [2-6]" \ >>> | nokeepalive ssl-unclean-shutdown \ >>> | downgrade-1.0 force-response-1.0 >>> | # MSIE 7 and newer should be able to use keepalive >>> | BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown >>> >>> in apache2.2-common 2.2.15-2. >>> >>>> I'm not an expert on how well SSL is supported in legacy user agents, >>>> but feature testing a client isn't as easy on the server as it is in >>>> JavaScript - the request header's all you've got to work on. >>> ACK >> Can you elaborate on that ACK? I can't imagine you are advocating that >> a Web server should change gears based on the UA header. (?) > > I was ACKnowledging the fact that "feature testing a client isn't as easy > on the server as it is in JavaScript - the request header's all you've got > to work on." Yes, that's certainly true. > > However, the logical conclusion is: *If* using a header field value is the > *only* way to satisfy compatibility with a client program deemed important > (which is not going to be fixed), then, and *only* then, it is acceptable > to do so. Yes. Iff. > Logic dictates that one shall accept the *probability* of false > positives (where basic functionality would still be guaranteed) when faced > with the alternative of *certain* dysfunctionality. The expression above > should be further refined, though, as there are still too many false > positives with it (Opera 5.02 to 8.0 for Windows being a distinct > possibility, for example). No question there. There's a lot of possibilities for false positives as it sits and *certainly* there are going to be lots of false positives with this approach, no matter how "refined" the sniffing.
From: David Mark on 30 Mar 2010 20:58 Stefan Weiss wrote: > On 31/03/10 01:11, Thomas 'PointedEars' Lahn wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> It (/etc/apache2/sites-available/default-ssl) has been changed to >>>> >>>> | BrowserMatch "MSIE [2-6]" \ >>>> | nokeepalive ssl-unclean-shutdown \ >>>> | downgrade-1.0 force-response-1.0 >>>> | # MSIE 7 and newer should be able to use keepalive >>>> | BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown >>>> >>>> in apache2.2-common 2.2.15-2. > [...] >> The expression above should be further refined, though, as there are >> still too many false positives with it (Opera 5.02 to 8.0 for Windows >> being a distinct possibility, for example). > > Or even more recent versions. In a collection of user agent strings > (which is admittedly over a year old), I found > > Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en) Opera 9.51 > > That would definitively be a false positive, and it's very likely that > newer Opera versions are also affected. My sympathy is somewhat limited, > though... that's what you get for masquerading as Mozilla and MSIE, when > you're neither. I have all the sympathy in the world for them. Opera 9-10 represent competent, standards-based browsers, yet are constantly running into exceptions on the Web (e.g. Google Adsense, MSDN, eBay and other huge sites that can't seem to buy a decent Web developer). They had no choice but to put on such a masquerade due to incompetently written scripts (the authors of which usually cop-out by blaming the users/browsers). It's the same reason that IE had no choice but to masquerade as Mozilla back during the "browser wars" of the late 90's. It is the authors of such scripts (and the site owners dumb enough to trust them) that I have no sympathy for. To this day, they write and deploy scripts that sniff the UA string, excluding users for no reason (other than their own incompetence) and truly seem to believe that it is the evil users/browsers that are making life hard for _them_. Talk to these people and terms like "pragmatic" and "real world" crop up immediately (and they translate to "idiotic" and "fantasy world" in my book). :) > Anyway, the Apache BrowserMatch directive should be > probably be refined to exclude Opera. I'll submit a patch if I can find > the time. Does anybody know if there are Opera versions which _do_ have > the same SSL problems as the old IEs? > > And finally, just for fun, when I grepped the user agent list for > "opera", I stumbled across this gem: > > mozilla/3.0b5pre with grabage in ua is neither Opera/9.20 nor msie7.0 > nor Safari or any other browser(it is not on any version of Windows > nor NT 6.0 nor on a mac but on linux; U;language hidden (en, en-us, > it, es, de, nl, fr, fi ???) hahahahahahahhaahh ) > > So much for trusting the UA string :) > So much indeed.
From: Stefan Weiss on 31 Mar 2010 21:28
On 31/03/10 02:58, David Mark wrote: > Stefan Weiss wrote: >> On 31/03/10 01:11, Thomas 'PointedEars' Lahn wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> It (/etc/apache2/sites-available/default-ssl) has been changed to >>>>> >>>>> | BrowserMatch "MSIE [2-6]" \ >>>>> | nokeepalive ssl-unclean-shutdown \ >>>>> | downgrade-1.0 force-response-1.0 >>>>> | # MSIE 7 and newer should be able to use keepalive >>>>> | BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown >>>>> >>>>> in apache2.2-common 2.2.15-2. >> [...] >>> The expression above should be further refined, though, as there are >>> still too many false positives with it (Opera 5.02 to 8.0 for Windows >>> being a distinct possibility, for example). >> >> Or even more recent versions. In a collection of user agent strings >> (which is admittedly over a year old), I found >> >> Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; en) Opera 9.51 >> >> That would definitively be a false positive, and it's very likely that >> newer Opera versions are also affected. My sympathy is somewhat limited, >> though... that's what you get for masquerading as Mozilla and MSIE, when >> you're neither. > > I have all the sympathy in the world for them. Opera 9-10 represent > competent, standards-based browsers, yet are constantly running into > exceptions on the Web (e.g. Google Adsense, MSDN, eBay and other huge > sites that can't seem to buy a decent Web developer). They had no > choice but to put on such a masquerade due to incompetently written > scripts (the authors of which usually cop-out by blaming the > users/browsers). It's the same reason that IE had no choice but to > masquerade as Mozilla back during the "browser wars" of the late 90's. > It is the authors of such scripts (and the site owners dumb enough to > trust them) that I have no sympathy for. To this day, they write and > deploy scripts that sniff the UA string, excluding users for no reason > (other than their own incompetence) and truly seem to believe that it is > the evil users/browsers that are making life hard for _them_. Talk to > these people and terms like "pragmatic" and "real world" crop up > immediately (and they translate to "idiotic" and "fantasy world" in my > book). :) I would call this UA charade the prototype of a pragmatic solution. The browsers are pretending to be something they're not, and they are specifically targetting badly written sniffer scripts. That's something you in particular would never condone if it were done in JS. It would be like... defining a global jQuery object in MyLibrary, and adding wrappers for their core methods -- just kidding! ;) Don't get me wrong, I think Opera is an outstanding piece of software, and I use it frequently. It comes with some very useful tools for developers, and it's more than adequate as a day-to-day browser. I even like the company's attitude. The only criticism I have is their lack of openness (as in opening their bug tracker and their source code), but that's just the way I tick. YMMV. I do understand why they did the UA trick, of course. It was a sensible business decision at the time, and in the long run, it has probably done more good than harm. At the very least, they're still in business, which I think is a good thing for the web ecosystem as a whole. But it's still a dirty hack, and being mistaken for an Internet Explorer when you're technically superior is one of the drawbacks. To put it another way: if you go out wearing a wig and a fancy dress, don't be surprised when that smelly wasted bum in the corner of the pub makes a pass at you :) -- stefan |