FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2009-06-27)
FAQ server
FAQ Topic - How can I see in javascript if a web browser
accepts cookies?
-----------------------------------------------------------------------
Write a cookie and read it back and check if it's the same.
http://www.w3schools.com/js/js_cookies.asp
Additional Notes:
http://www.jibbering.com/faq/faq_notes/cookies.html
http://www.ietf.org/rfc/rfc2965.txt
http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
kangax
> -----------------------------------------------------------------------
> FAQ Topic - How can I see in javascript if a web browser
> accepts cookies?
> -----------------------------------------------------------------------
>
> Write a cookie and read it back and check if it's the same.
>
> http://www.w3schools.com/js/js_cookies.asp
Isn't w3schools.com recommended against in this group?
[...]
--
kangax
David Mark
With extreme prejudice. As expected, the code in the cited example is
garbage. That link should definitely be removed.
Garrett Smith
By me it is. I think Thomas, too.
Checking that... ouch -- bad code there! It will perform incorrectly,
assign to the global object. I just noticed that in 2 sec scan of the
code. That link needs to be removed, pronto!
The "notes" article on cookies recommends that, too[1]. That article
needs fixing, too. The code has a similar bug to the w3schools article
in that it will return the first match of a cookie by that name, not the
last. Get_Cookie should also be renamed to getCookie(), and likewise for
"Set_Cookie". ECMA recommends favoring toUTCString over toGMTString,
though that may be less widely supported, though how much so, I do not
know. I checked Thomas' es-matrix and did not see any of the
"Date.prototype.toXXX" methods.
A more reliable example for the FAQ is in order. Who's gonna write one?
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
[1]http://www.jibbering.com/faq/faq_notes/cookies.html
Thomas 'PointedEars' Lahn
> ECMA recommends favoring toUTCString over toGMTString, though that may be
> less widely supported, though how much so, I do not know. I checked Thomas'
> es-matrix and did not see any of the "Date.prototype.toXXX" methods.
Thanks for pointing out. The local version had only .toLocaleString().
Compatibility per my current research is as follows:
JavaScript JScript ES JSC² KJS³ Opera
___________________________________________________________________________
.toDateString() 1.8 (N/A) 5.5.6330 (5.5) 3 530.17 3.5.9 5.02
.toGMTString() [S] 1.3 (1.0¹) 5.1.5010 (1.0) 1 530.17 3.5.9 5.02
.toLocaleDateString() 1.8 (1.0*) 5.5.6330 (5.5) 3 530.17 3.5.9 5.02
.toLocaleFormat(...) 1.8 (1.6) - - - - - -
.toLocaleString() [S] 1.3 (1.0) 5.1.5010 (1.0) 1 525.13 3.5.9 5.02
.toLocaleTimeString() 1.8 (1.0*) 5.5.6330 (5.5) 3 530.17 3.5.9 5.02
.toString() [S] 1.3 (1.1) 5.1.5010 (2.0) 1 530.17 3.5.9 5.02
.toSource() 1.3 (1.3) - - - - - -
.toTimeString() 1.8 (N/A) 5.5.6330 (5.5) 3 530.17 3.5.9 5.02
.toUTCString() [S] 1.3 (1.3) 5.1.5010 (3.0) 1 530.17 3.5.9 5.02
The versions here I have tested to date; text in parantheses denotes what is
documented instead, `*' denotes documentation that contradicts tests.
The completed Matrix (at <http://PointedEars.de/es-matrix>) will probably
feature sourced, documented, assumed, and tested versions. The versions
here denote the minimum requirements; newer versions are expected to support
the respective feature, too; tests have not shown otherwise.
Features marked with `[S]' can be considered safe according to these results
and based on the assumption that earlier versions are obsolete because the
user agents known to implement them can be considered obsolete. Note that
this assessment is likely to be subject to change as more implementations
are evaluated. If taken as a recommendation for design decisions, it should
be taken as a light one.
Relevant test environments were:
JavaScript
-----------
1.3: "Mozilla/4.78 [de] (Windows NT 5.0; U)"
1.8: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212
Iceweasel/3.0.11 (Debian-3.0.11-1)"
JScript
--------
5.1.5010: "Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)"
5.5.6330: "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
5.6.6626: "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
JavaScriptCore
---------------
525.13: "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE)
AppleWebKit/525.13 (KHTML, like Gecko) Version/3.?.? Safari/525.??"
530.17: "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE)
AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17"
KJS
----
"Mozilla/5.0 (compatible; Konqueror/3.5;
Linux 2.6.29.4-20090531.213230+0200; X11; i686; de, en_US)
KHTML/3.5.10 (like Gecko) (Debian package 4:3.5.10.dfsg.1-2)"
Opera
------
"Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.1) Opera 5.02 [en]"
"Mozilla/4.0 (compatible; MSIE 5.0; Windows XP) Opera 6.06 [en]"
"Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1)
Opera 7.02 [en]"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.0"
"Opera/9.27 (Windows NT 5.1; U; en)"
HTH
PointedEars
___________
¹ Deprecated since JavaScript 1.3
² Apple JavaScriptCore as used in WebKit-based UAs
³ Konqueror JavaScript as used in KHTML-based UAs
Dr J R Stockton
30 Jun 2009 18:58:16, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>Garrett Smith wrote:
>> ECMA recommends favoring toUTCString over toGMTString, though that may be
>> less widely supported, though how much so, I do not know. I checked Thomas'
>> es-matrix and did not see any of the "Date.prototype.toXXX" methods.
>Features marked with `[S]' can be considered safe according to these results
No form of date tostring can be considered safe according to the
Mark criteria because the applicable standard permits both DD/MM/YYYY
and MM/DD/YYYY. Execution without the system raising an error is a
necessary, but not a sufficient, criterion for safety; safety requires
that the results are unambiguously correct.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn posted:
>> Garrett Smith wrote:
>>> ECMA recommends favoring toUTCString over toGMTString, though that may be
>>> less widely supported, though how much so, I do not know. I checked Thomas'
>>> es-matrix and did not see any of the "Date.prototype.toXXX" methods.
>
>> Features marked with `[S]' can be considered safe according to these results
>
> No form of date tostring can be considered safe according to the
> Mark criteria because the applicable standard permits both DD/MM/YYYY
> and MM/DD/YYYY. Execution without the system raising an error is a
> necessary, but not a sufficient, criterion for safety; safety requires
> that the results are unambiguously correct.
Thanks. "Safe" in the ECMAScript Support Matrix currently means only
"appears to be so widely supported that it may be called without prior
feature test". I might include tests as to whether a feature's (return)
value is reliable or useful later.
PointedEars
Garrett Smith
A marker for either "implementation dependent" absolves the need for
tests and avoids making things appear consistent when it might be
uncertain.
I've updated the entry. Will upload after the "getElementById" entry is
complete. Seems to be be nearly done; just waiting for more review.
Dr J R Stockton
>I've updated the entry. Will upload after the "getElementById" entry is
>complete. Seems to be be nearly done; just waiting for more review.
You should not be trying to write FAQ entries on your own, with or
without a small group of associates' you should be doing it publicly,
here.
Doing it on your own (or ...) means that, when the new entry is
revealed, there will be comment and criticism here to be dealt with; so,
in the end, time will have been wasted.
It also means that you may unilaterally reject a suggestion, for example
one that you have not fully understood; if you were working publicly
others would have seen that suggestion and would be able to rephrase and
strengthen the arguments.
Significant changes to the FAQ should not be made until AFTER they have
been posted here AND given sufficient time for comment to have been
considered, tested, and received here, and the discussion has died down
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Garrett Smith
>> complete. Seems to be be nearly done; just waiting for more review.
>
>
> You should not be trying to write FAQ entries on your own, with or
> without a small group of associates' you should be doing it publicly,
> here.
>
comments. Got any?
I have not written an FAQ Entry on my own. What is the purpose of
suggesting that?
I have not done anything other than remove two links.
> Doing it on your own (or ...) means that, when the new entry is
> revealed, there will be comment and criticism here to be dealt with; so,
> in the end, time will have been wasted.
If we're lucky, we'll get a new example next time around. I have a lot
of backlog to upload.
>
> It also means that you may unilaterally reject a suggestion, for example
> one that you have not fully understood; if you were working publicly
> others would have seen that suggestion and would be able to rephrase and
> strengthen the arguments.
>
In this case, I accepted a suggestion and stated so clearly, in this
thread.
> Significant changes to the FAQ should not be made until AFTER they have
> been posted here AND given sufficient time for comment to have been
> considered, tested, and received here, and the discussion has died down
>
A lot of small changes adds up, and the longer I keep these on my
machine, the more of them accumulate. So, if you want to see it, here it
is:-
| 8.9 How can I see in javascript if a web browser accepts cookies?
|
| Write a cookie and read it back and check if it's the same.
|
| * Additional Notes:
| * http://www.ietf.org/rfc/rfc2965.txt
| * http://www.galasoft-lb.ch/myjavascript/consulting/2001012701/
| * http://www.cookiecentral.com/
See, no more w3schools link and no more link to the faq notes page.
Removed for reasons stated and that was not objected to by anyone.
When jibbering is back, I'll upload that and the four other entry changes.