Prev: how to get url of script
Next: question of logic?
From: David Mark on 21 Mar 2010 21:21 Stefan Weiss wrote: > On 20/03/10 22:21, David Mark wrote: >> Andrea Giammarchi wrote: >>> On Mar 20, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>> As I have said, all your base are belong to us. >>> ... if you like to think it, please feel free to do it (btw, recycled >>> typo not even fun anymore ... did you play only that game?) >> What game? > > Zero Wing. Your quote. I'll take your word for it. I simply know it as a famous malaprop. > >>> However, most web servers are still configured to rely into userAgent >>> strings to redirect pages, serve files, etc etc ... >> 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 Hopefully the author of that is now in a ditch somewhere (digging it I mean). :) > > Looks rather heavy handed... > "Back to the '90s, Opera! Here's some HTTP/1.0 for you." And, of course, there is no guarantee as to which browsers will receive that treatment. Apparently the author has never heard of proxy servers (among other things). :( > > 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. > But the UA header is simply an arbitrary (and optional) string of characters with no correlation to SSL at all. ;)
From: Thomas 'PointedEars' Lahn on 21 Mar 2010 23:13 Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> I have no list, but I have read here from people I trust they know what >> they are saying and doing (so not you) that there are relevant mobile >> devices that do not implement all features of ES 3 to save memory. > > Would this be WMLScript? Unlikely. If you knew you would be writing a WAP application, you would skip those features not in WMLScript to begin with. And wasn't WAP dead already? I am talking about scripts and mobile devices that, e.g. would run fine if you did not use instanceof when not necessary, and hid try-catch from their compilers. And I still have no list, so please stop asking. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Richard Cornford on 22 Mar 2010 10:12 On Mar 20, 7:45 pm, Andrea Giammarchi wrote: > P.S. > > Boolean.isInstance = function (o) { > return !!o && o.constructor === this; > > }; > > Boolean.isInstance(false); // false That would seem to be a correct outcome. A boolean primitive value is not an object and so is not an instance of any type of object. If something is going to be the subject of complain in relation to your code then it should be that:- Boolean.isInstance(true); // true - results in true for a primitive value (which is not an object and therefore not an instance of any type of object). > maybe a generic isInstance, whoever will use it, should be more like: A generic isInstance method/algorithm would be a futile pursuit. Beyond the problem that there are at least three completely valid opinions on what being an instance of something represents, the need to know is sufficiently uncommon that in the few cases that such an identification is needed it is simpler to provide the objects that need the facility with a direct means of making the discrimination. > Boolean.isInstance = function (o) { > return o != null && o.constructor === this; > > }; Now you get the incorrect - true - result if either boolean primitive is used as an argument, which is worse. Richard.
From: Thomas 'PointedEars' Lahn on 30 Mar 2010 09:07 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 PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Stefan Weiss on 30 Mar 2010 13:13
On 30/03/10 15:07, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: >> 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. Interesting. The default SSL config for 2.2.15 from apache.org still has the ".*MSIE.*" catch-all, so this change was probably introduced by the Debian package maintainer. IIRC, Lenny (stable) still runs Apache 2.2.9, but Squeeze (testing) is at version 2.2.15-2 - I guess that's what you're using. Ah, I found it: <URL:http://svn.debian.org/viewsvn/pkg-apache?view=rev&revision=1087> They fixed this on 2009-11-07. It's always nice to see how the maintainers are often a step ahead of my complaints ;-) Thanks for the info. -- stefan |