[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