[html5] r1848 - [e] (0) Make HTML5 agnostic regarding Cookie and Cookie2. (Re: Web Sockets) (cre [...]
whatwg at whatwg.org
whatwg at whatwg.org
Sat Jul 5 17:08:51 PDT 2008
Author: ianh
Date: 2008-07-05 17:08:49 -0700 (Sat, 05 Jul 2008)
New Revision: 1848
Modified:
index
source
Log:
[e] (0) Make HTML5 agnostic regarding Cookie and Cookie2. (Re: Web Sockets) (credit: ns)
Modified: index
===================================================================
--- index 2008-07-03 20:51:44 UTC (rev 1847)
+++ index 2008-07-06 00:08:49 UTC (rev 1848)
@@ -25,7 +25,7 @@
<h1 id=html-5>HTML 5</h1>
- <h2 class="no-num no-toc" id=draft>Draft Recommendation — 3 July
+ <h2 class="no-num no-toc" id=draft>Draft Recommendation — 6 July
2008</h2>
<p>You can take part in this work. <a
@@ -6636,8 +6636,9 @@
must return the same string as the value of the <code
title="">Cookie</code> HTTP header it would include if fetching the
resource indicated by <span>the document's
- address</span><!-- XXXDOCURL --> over HTTP, as per RFC 2109 section 4.3.4.
- <a href="#refsRFC2109">[RFC2109]</a>
+ address</span><!-- XXXDOCURL --> over HTTP, as per RFC 2109 section 4.3.4
+ or later specifications. <a href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a>
<p>On setting, if the <a href="#sandboxed2">sandboxed origin browsing
context flag</a> is set on the <a href="#browsing1">browsing context</a>
@@ -6646,8 +6647,8 @@
processing cookies if it had just attempted to fetch <span>the document's
address</span><!-- XXXDOCURL --> over HTTP, and had received a response
with a <code>Set-Cookie</code> header whose value was the specified value,
- as per RFC 2109 sections 4.3.1, 4.3.2, and 4.3.3. <a
- href="#refsRFC2109">[RFC2109]</a>
+ as per RFC 2109 sections 4.3.1, 4.3.2, and 4.3.3 or later specifications.
+ <a href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a>
<p class=note>Since the <code title=dom-document-cookie><a
href="#cookie0">cookie</a></code> attribute is accessible across frames,
@@ -35143,7 +35144,7 @@
<p>This specification introduces two related mechanisms, similar to HTTP
session cookies, for storing structured data on the client side. <a
- href="#refsRFC2965">[RFC2965]</a> <a href="#refsRFC2109">[RFC2109]</a>
+ href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a>
<p>The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
@@ -36192,7 +36193,7 @@
<p>Treating persistent storage as cookies: user agents should present the
persistent storage and database features to the user in a way that does
not distinguish them from HTTP session cookies. <a
- href="#refsRFC2965">[RFC2965]</a> <a href="#refsRFC2109">[RFC2109]</a></p>
+ href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a></p>
<p>This might encourage users to view persistent storage with healthy
suspicion.</p>
@@ -36525,7 +36526,7 @@
<p>User agents must ignore any entity bodies returned in the responses, but
must, unless otherwise specified by the user, honor the HTTP headers
(including, in particular, redirects and HTTP cookie headers). <a
- href="#refsRFC2965">[RFC2965]</a> <a href="#refsRFC2109">[RFC2109]</a>
+ href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a>
<p>When the <code title=attr-hyperlink-ping><a href="#ping">ping</a></code>
attribute is present, user agents should clearly indicate to the user that
@@ -41595,7 +41596,7 @@
true and is otherwise identical to <var title="">url</var>, then HTTP
headers that would be appropriate for that information should be sent at
this point. <a href="#refsRFC2616">[RFC2616]</a> <a
- href="#refsRFC2965">[RFC2965]</a> <a href="#refsRFC2109">[RFC2109]</a></p>
+ href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a></p>
<p>Each header must be on a line of its own (each ending with a CR LF
sequence). For the purposes of this step, each header must not be split
@@ -41794,7 +41795,7 @@
<code title="">http</code> if <var title="">secure</var> is false and
<code title="">https</code> if <var title="">secure</var> is true and
is otherwise identical to <var title="">url</var>. <a
- href="#refsRFC2965">[RFC2965]</a> <a href="#refsRFC2109">[RFC2109]</a>
+ href="#refsRFC2109">[RFC2109]</a> <a href="#refsRFC2965">[RFC2965]</a>
<dt>Any other name
Modified: source
===================================================================
--- source 2008-07-03 20:51:44 UTC (rev 1847)
+++ source 2008-07-06 00:08:49 UTC (rev 1848)
@@ -4880,7 +4880,9 @@
string as the value of the <code title="">Cookie</code> HTTP header
it would include if fetching the resource indicated by <span>the
document's address</span><!-- XXXDOCURL --> over HTTP, as per RFC
- 2109 section 4.3.4. <a href="#refsRFC2109">[RFC2109]</a></p>
+ 2109 section 4.3.4 or later specifications. <a
+ href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p>On setting, if the <span>sandboxed origin browsing context
flag</span> is set on the <span>browsing context</span> of the
@@ -4890,7 +4892,9 @@
document's address</span><!-- XXXDOCURL --> over HTTP, and had
received a response with a <code>Set-Cookie</code> header whose
value was the specified value, as per RFC 2109 sections 4.3.1,
- 4.3.2, and 4.3.3. <a href="#refsRFC2109">[RFC2109]</a></p>
+ 4.3.2, and 4.3.3 or later specifications. <a
+ href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p class="note">Since the <code
title="dom-document-cookie">cookie</code> attribute is accessible
@@ -32828,8 +32832,8 @@
<p>This specification introduces two related mechanisms, similar to
HTTP session cookies, for storing structured data on the client
- side. <a href="#refsRFC2965">[RFC2965]</a> <a
- href="#refsRFC2109">[RFC2109]</a></p>
+ side. <a href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p>The first is designed for scenarios where the user is carrying
out a single transaction, but could be carrying out multiple
@@ -33879,8 +33883,8 @@
<p>Treating persistent storage as cookies: user agents should
present the persistent storage and database features to the user
in a way that does not distinguish them from HTTP session
- cookies. <a href="#refsRFC2965">[RFC2965]</a> <a
- href="#refsRFC2109">[RFC2109]</a></p>
+ cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p>This might encourage users to view persistent storage with
healthy suspicion.</p>
@@ -34246,8 +34250,8 @@
<p>User agents must ignore any entity bodies returned in the
responses, but must, unless otherwise specified by the user, honor
the HTTP headers (including, in particular, redirects and HTTP
- cookie headers). <a href="#refsRFC2965">[RFC2965]</a> <a
- href="#refsRFC2109">[RFC2109]</a></p>
+ cookie headers). <a href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p>When the <code title="attr-hyperlink-ping">ping</code> attribute is
present, user agents should clearly indicate to the user that
@@ -39165,8 +39169,8 @@
<var title="">url</var>, then HTTP headers that would be
appropriate for that information should be sent at this point. <a
href="#refsRFC2616">[RFC2616]</a> <a
- href="#refsRFC2965">[RFC2965]</a> <a
- href="#refsRFC2109">[RFC2109]</a></p>
+ href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></p>
<p>Each header must be on a line of its own (each ending with a CR
LF sequence). For the purposes of this step, each header must not
@@ -39419,8 +39423,8 @@
scheme of <code title="">http</code> if <var
title="">secure</var> is false and <code title="">https</code> if
<var title="">secure</var> is true and is otherwise identical to
- <var title="">url</var>. <a href="#refsRFC2965">[RFC2965]</a> <a
- href="#refsRFC2109">[RFC2109]</a></dd>
+ <var title="">url</var>. <a href="#refsRFC2109">[RFC2109]</a> <a
+ href="#refsRFC2965">[RFC2965]</a></dd>
<dt>Any other name</dt>
More information about the Commit-Watchers
mailing list