From: David Mark on
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
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
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
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
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: how to get url of script
Next: question of logic?