[html5] r3740 - [] (0) Integrate with draft-abarth-cookie-03.
whatwg at whatwg.org
whatwg at whatwg.org
Thu Sep 3 05:15:57 PDT 2009
Author: ianh
Date: 2009-09-03 05:15:56 -0700 (Thu, 03 Sep 2009)
New Revision: 3740
Modified:
index
source
Log:
[] (0) Integrate with draft-abarth-cookie-03.
Modified: index
===================================================================
--- index 2009-09-03 11:59:39 UTC (rev 3739)
+++ index 2009-09-03 12:15:56 UTC (rev 3740)
@@ -5001,7 +5001,7 @@
<li><p>Take ownership of the <a href=#storage-mutex>storage mutex</a>.</li>
- <li><p>Update the cookies. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsCOOKIES>[COOKIES]</a></li>
+ <li><p>Update the cookies. <a href=#refsCOOKIES>[COOKIES]</a></li>
<li><p>Release the <a href=#storage-mutex>storage mutex</a> so that it is once
again free.</li>
@@ -6840,12 +6840,9 @@
<code><a href=#security_err>SECURITY_ERR</a></code> exception. Otherwise, if <a href="#the-document's-address">the
document's address</a> does not use a server-based naming
authority, it must return the empty string. Otherwise, it must first
- <a href=#obtain-the-storage-mutex>obtain the storage mutex</a> and then return the same
- string as the value of the <code title="">Cookie</code> HTTP header
- it would include if <a href=#fetch title=fetch>fetching</a> the resource
- indicated by <a href="#the-document's-address">the document's address</a> over HTTP, as per
- RFC 2109 section 4.3.4 or later specifications, excluding HTTP-only
- cookies. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsCOOKIES>[COOKIES]</a></p>
+ <a href=#obtain-the-storage-mutex>obtain the storage mutex</a> and then return the
+ cookie-string for <a href="#the-document's-address">the document's address</a> for a
+ "non-HTTP" API. <a href=#refsCOOKIES>[COOKIES]</a></p>
<p>On setting, if the document is not associated with a
<a href=#browsing-context>browsing context</a> then the user agent must raise an
@@ -6857,19 +6854,10 @@
document's address</a> does not use a server-based naming
authority, it must do nothing. Otherwise, the user agent must
<a href=#obtain-the-storage-mutex>obtain the storage mutex</a> and then act as it would when
- processing cookies if it had just attempted to <a href=#fetch>fetch</a>
- <a href="#the-document's-address">the document's address</a> 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 or
- later specifications, but without overwriting the values of
- HTTP-only cookies. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsCOOKIES>[COOKIES]</a></p>
+ <span title="receives a set-cookie-string">receiving a
+ set-cookie-string</span> for <a href="#the-document's-address">the document's address</a> via
+ a "non-HTTP" API, consisting of the new value. <a href=#refsCOOKIES>[COOKIES]</a></p>
- <p class=note>This specification does not define what makes an
- HTTP-only cookie, and at the time of publication the editor is not
- aware of any reference for HTTP-only cookies. They are a feature
- supported by some Web browsers wherein an "<code title="">httponly</code>" parameter added to the cookie string
- causes the cookie to be hidden from script.</p>
-
<p class=note>Since the <code title=dom-document-cookie><a href=#dom-document-cookie>cookie</a></code> attribute is accessible
across frames, the path restrictions on cookies are only a tool to
help manage which cookies are sent to which parts of the site, and
@@ -53865,7 +53853,7 @@
the HTTP headers (including, in particular, redirects and HTTP
cookie headers), but must ignore any entity bodies returned in the
responses. User agents may close the connection prematurely once
- they start receiving an entity body. <a href=#refsRFC2109>[RFC2109]</a> <a href=#refsCOOKIES>[COOKIES]</a></p>
+ they start receiving an entity body. <a href=#refsCOOKIES>[COOKIES]</a></p>
<p>For URLs that are not HTTP URLs, the requests must be performed
by <a href=#fetch title=fetch>fetching</a> the specified URL normally,
@@ -74004,10 +73992,6 @@
N. Borenstein. IETF, November 1996.</dd> <!-- for text/plain and
"Internet Media type"; not for definition of "valid MIME type". -->
- <dt id=refsRFC2109>[RFC2109]</dt>
- <dd><cite><a href=http://www.ietf.org/rfc/rfc2109.txt>HTTP State Management
- Mechanism</a></cite>, D. Kristol, L. Montulli. IETF, February 1997.</dd>
-
<dt id=refsRFC2119>[RFC2119]</dt>
<dd><cite><a href=http://www.ietf.org/rfc/rfc2119.txt>Key words for use in
RFCs to Indicate Requirement Levels</a></cite>, S. Bradner. IETF, March
Modified: source
===================================================================
--- source 2009-09-03 11:59:39 UTC (rev 3739)
+++ source 2009-09-03 12:15:56 UTC (rev 3740)
@@ -4700,7 +4700,7 @@
<li><p>Take ownership of the <span>storage mutex</span>.</p></li>
- <li><p>Update the cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
+ <li><p>Update the cookies. <a
href="#refsCOOKIES">[COOKIES]</a></p></li>
<li><p>Release the <span>storage mutex</span> so that it is once
@@ -6828,13 +6828,9 @@
<code>SECURITY_ERR</code> exception. Otherwise, if <span>the
document's address</span> does not use a server-based naming
authority, it must return the empty string. Otherwise, it must first
- <span>obtain the storage mutex</span> and then return the same
- string as the value of the <code title="">Cookie</code> HTTP header
- it would include if <span title="fetch">fetching</span> the resource
- indicated by <span>the document's address</span> over HTTP, as per
- RFC 2109 section 4.3.4 or later specifications, excluding HTTP-only
- cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
- href="#refsCOOKIES">[COOKIES]</a></p>
+ <span>obtain the storage mutex</span> and then return the
+ cookie-string for <span>the document's address</span> for a
+ "non-HTTP" API. <a href="#refsCOOKIES">[COOKIES]</a></p>
<p>On setting, if the document is not associated with a
<span>browsing context</span> then the user agent must raise an
@@ -6846,21 +6842,11 @@
document's address</span> does not use a server-based naming
authority, it must do nothing. Otherwise, the user agent must
<span>obtain the storage mutex</span> and then act as it would when
- processing cookies if it had just attempted to <span>fetch</span>
- <span>the document's address</span> 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 or
- later specifications, but without overwriting the values of
- HTTP-only cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
+ <span title="receives a set-cookie-string">receiving a
+ set-cookie-string</span> for <span>the document's address</span> via
+ a "non-HTTP" API, consisting of the new value. <a
href="#refsCOOKIES">[COOKIES]</a></p>
- <p class="note">This specification does not define what makes an
- HTTP-only cookie, and at the time of publication the editor is not
- aware of any reference for HTTP-only cookies. They are a feature
- supported by some Web browsers wherein an "<code
- title="">httponly</code>" parameter added to the cookie string
- causes the cookie to be hidden from script.</p>
-
<p class="note">Since the <code
title="dom-document-cookie">cookie</code> attribute is accessible
across frames, the path restrictions on cookies are only a tool to
@@ -60875,8 +60861,7 @@
<p>This specification introduces two related mechanisms, similar to
HTTP session cookies, for storing structured data on the client
- side. <a href="#refsRFC2109">[RFC2109]</a> <a
- href="#refsCOOKIES">[COOKIES]</a></p>
+ side. <a href="#refsCOOKIES">[COOKIES]</a></p>
<p>The first is designed for scenarios where the user is carrying
out a single transaction, but could be carrying out multiple
@@ -62554,8 +62539,7 @@
database feature
<!--START storage-->
to the user in a way that does not distinguish them from HTTP
- session cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
- href="#refsCOOKIES">[COOKIES]</a></p>
+ session cookies. <a href="#refsCOOKIES">[COOKIES]</a></p>
<p>This might encourage users to view such storage with healthy
suspicion.</p>
@@ -62987,7 +62971,6 @@
cookie headers), but must ignore any entity bodies returned in the
responses. User agents may close the connection prematurely once
they start receiving an entity body. <a
- href="#refsRFC2109">[RFC2109]</a> <a
href="#refsCOOKIES">[COOKIES]</a></p>
<p>For URLs that are not HTTP URLs, the requests must be performed
@@ -87944,10 +87927,6 @@
N. Borenstein. IETF, November 1996.</dd> <!-- for text/plain and
"Internet Media type"; not for definition of "valid MIME type". -->
- <dt id="refsRFC2109">[RFC2109]</dt>
- <dd><cite><a href="http://www.ietf.org/rfc/rfc2109.txt">HTTP State Management
- Mechanism</a></cite>, D. Kristol, L. Montulli. IETF, February 1997.</dd>
-
<dt id="refsRFC2119">[RFC2119]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in
RFCs to Indicate Requirement Levels</a></cite>, S. Bradner. IETF, March
More information about the Commit-Watchers
mailing list