- From: Michael(tm) Smith <mike@w3.org>
- Date: Wed, 23 Jan 2008 23:04:22 +0900
- To: Anne van Kesteren <annevk@opera.com>
- Cc: www-archive@w3.org
- Message-ID: <20080123140414.GA14911@sideshowbarker>
Anne,
This is the diff of the editorial tweaks I made to the AC spec
today. Almost all the changes for this commit just amounted to
adding commas and parenthesis. I'll look into wordsmithing changes
later. I think Thomas also has some editorial comments he's
working on wrapping up.
--Mike
===================================================================
RCS file: /sources/public/2006/waf/access-control/Overview.src.html,v
retrieving revision 1.138
retrieving revision 1.139
diff -u -r1.138 -r1.139
--- 2006/waf/access-control/Overview.src.html 2008/01/22 23:12:45 1.138
+++ 2006/waf/access-control/Overview.src.html 2008/01/23 13:26:59 1.139
@@ -124,11 +124,12 @@
<h2 id="introduction">Introduction</h2>
- <p>In the broad sense a cross-site request is a request from domain
- <var>A</var> to domain <var>B</var> initiated by some code in a Web page.
- An HTML <code>img</code> element on an <code>example.org</code> Web page
+ <p>In the broad sense, a cross-site request is a request from domain
+ <var>A</var> to domain <var>B</var>, initiated by some code in a Web page.
+ An example of such a cross-site request is
+ an HTML <code>img</code> element on an <code>example.org</code> Web page
that causes a request to be made to an image on the
- <code>hello-world.invalid</code> domain for instance.</p>
+ <code>hello-world.invalid</code> domain.</p>
<p>Since these requests are made using the user's authentication
information for domain <var>B</var>, if any, there is a restriction,
@@ -141,9 +142,9 @@
<code>img</code> element this is less of a problem as there is no way to
read the contents of the image resource.</p>
- <p>This specification introduces an access control policy so that a
+ <p>This specification introduces an access-control policy so that a
resource can opt-in to allowing a Web site residing at another domain to
- request the data of the resource using the HTTP <code>GET</code>.
+ request the data of the resource using the HTTP <code>GET</code> method.
Specifications that define technologies that allow for such requests, such
as <code>XMLHttpRequest</code> and XBL, will have to define how the policy
applies to their model.</p>
@@ -153,26 +154,26 @@
cases</a>. A FAQ describing the <a href="#design-decision-faq">design
decisions</a> is also available.</p>
- <p>This document also introduces an access control policy that allows a
- resource to opt-in to cross-site requests using another HTTP method than
- <code>GET</code>. When such a request is initiated from a Web page the
+ <p>This document also introduces an access-control policy that allows a
+ resource to opt-in to cross-site requests using an HTTP method other than
+ <code>GET</code>. When such a request is initiated from a Web page, the
user agent will first make an authentication request (which will be
cached) and then make the actual request using the desired HTTP method.
This will be useful for cross-site manipulation of resources.</p>
<p class="note">It is possible to make cross-site requests using the HTML
<code>form</code> element with the HTTP <code>POST</code> method. However,
- this provides less capabilities on the requesting side compared to
+ that provides less capabilities on the requesting side compared to
<code>XMLHttpRequest</code> and does not expose the response of the
request. Therefore the authorization request is required for the HTTP
<code>POST</code> method too. The functionality described in this
specification does not affect the way the HTML <code>form</code> element
functions.</p>
- <p>To summarize, the access control policy is defined in the resource that
+ <p>To summarize, the access-control policy is defined in the resource that
might be obtained and is expected to be enforced by the client that
retrieves and processes the resource. Thus the client is trusted and acts
- as a policy enforcement point.</p>
+ as a policy enforcement point (PEP).</p>
<div class="example">
<p>If you have a simple text resource residing at
@@ -185,8 +186,8 @@
Hello World!</code></pre>
- <p>The <code>hello-world.invalid</code> can now access this document
- using <code>XMLHttpRequest</code> for instance with the following
+ <p>The <code>hello-world.invalid</code> domain can now access this document
+ using <code>XMLHttpRequest</code>; for instance, with the following
code:</p>
<pre><code>new client = new XMLHttpRequest();
@@ -198,24 +199,24 @@
to handle cross-site requests using the HTTP <code>DELETE</code> and
<code>POST</code> methods. Your resource first needs to reply to an
authorization request that uses the <code>OPTIONS</code> method and has
- the <code>Method-Check</code> HTTP header set and then needs to handle
+ the <code>Method-Check</code> HTTP header set, and then needs to handle
the request that uses the <code>POST</code> or <code>DELETE</code> method
and give an appropriate response. The reply to the authorization request
- can have the following HTTP headers specified for instance:</p>
+ can have the following HTTP headers specified (for instance):</p>
<pre><code>Access-Control: allow <hello-world.invalid> method DELETE POST
Method-Check-Expires: Sun, 06 Nov 2012 08:49:37 GMT</code></pre>
- <p>The <code>Method-Check-Expires</code> indicates how long the response
- can be cached so that for subsequent requests involving the HTTP
- <code>DELETE</code> and <code>POST</code> methods no authorization
+ <p>The <code>Method-Check-Expires</code> header indicates how long the response
+ can be cached, so that for subsequent requests involving the HTTP
+ <code>DELETE</code> and <code>POST</code> methods, no authorization
request has to be made. The response to the actual request can simply
contain this header:</p>
<pre><code>Access-Control: allow <hello-world.invalid></code></pre>
- <p>As opposed to handling such a request, actually making a request like
- that is not difficult as the complexity of doing the additional
+ <p>In contrast to handling such a request, actually making a request like
+ that is not difficult, as the complexity of doing the additional
authorization request is the task of the user agent. Using
<code>XMLHttpRequest</code> again and assuming the application were
hosted at <code>http://calendar.invalid/app</code> you could do something
@@ -258,7 +259,7 @@
<p>This specification is applicable to <em>both</em> user agents and
other specifications. This specification will only apply in certain
- contexts and specifications defining such contexts will define when and
+ contexts, and specifications defining such contexts will define when and
how this specification applies.</p>
<p>As well as sections marked as non-normative, all diagrams, examples,
@@ -279,7 +280,7 @@
<p>A conformant user agent is one that implements all the requirements
listed in this specification that are applicable to user agents, while
also being consistent with the requirements listed in the specifications
- that use the <span>access control read policy</span>.</p>
+ that use the <span>access-control read policy</span>.</p>
<p>User agents <em class="ct">may</em> optimize any algorithm given in
this specification, so long as the end result is indistinguishable from
@@ -334,11 +335,11 @@
<h2 id="security">Security Considerations</h2>
- <p>The access control mechanism defined in this specification allows for
+ <p>The access-control mechanism defined in this specification allows for
extension of the same-origin policy in contexts where the same-origin
policy currently applies.</p>
- <p>When making a <span>cross-site access request</span> user agents
+ <p>When making a <span>cross-site access request</span>, user agents
<em class="ct">should</em> ensure to:</p>
<ul>
@@ -346,17 +347,17 @@
been granted. This prevents port scanning and finding out about intranet
servers the user might be connected with.</li>
- <li>Not to expose any trusted data of the response, such as cookies, and
- HTTP header data, inappropriately.</li>
+ <li>Not inappropriately expose any trusted data of the response, such as cookies and
+ HTTP header data.</li>
<li>Not allow the author to set cookies or authentication credentials for
- the request as this would allow for a distributed cookie or credentials
+ the request, as this would allow for a distributed cookie or credentials
search.</li>
</ul>
<p>User agents which implement this specification
<em class="ct">must</em> also take care to properly normalize Unicode
- and to properly interpret IDNs to prevent URI spoofing attacks as outlined
+ and to properly interpret IDNs to prevent URI spoofing attacks, as outlined
in the specification. [<cite><span>RFC3490</span></cite>]</p>
<p>Application authors <em class="ct">should</em> be aware that content
@@ -379,11 +380,11 @@
<p>Now <code>company.invalid</code> happens to be on a shared hosting
environment with <code>evil.example.net</code> (they share the IP
- address). Because of this <code>evil.example.net</code> can host content
+ address). Because of this, <code>evil.example.net</code> can host content
at <code>company.invalid:9999</code> and access user-sensitive data at
<code>example.com</code> if the user, by phishing for instance, goes to
<code>company.invalid:9999</code>. This can be prevented by clearly
- specifying the port or omitting it entirely letting it default to the
+ specifying the port or omitting it entirely, letting it default to the
default port of the URI scheme:</p>
<ul>
@@ -393,19 +394,19 @@
</div>
<p>Authors <em class="ct">should</em> ensure that <code>GET</code>
- requests on their application has no side effects. If by some means an
- evil application finds out what applications a user is associated with it
+ requests on their application have no side effects. If by some means an
+ evil application finds out what applications a user is associated with, it
might "attack" these applications with <code>GET</code> requests that can
- effect the user's data if the user is already authenticated with any of
- these applications by means of cookies or HTTP authentication.</p>
+ effect the user's data (if the user is already authenticated with any of
+ these applications by means of cookies or HTTP authentication).</p>
<p>Authors are encouraged to check the <code>Referer-Root</code> HTTP
header, especially for non-<code>GET</code> requests, to ensure that in
case of policy change they do not inadvertently allow access due to race
- conditions when it should be denied.</p>
+ conditions (when such access should be denied).</p>
- <p>Integrity protection of the access control policy statements may be
- required. This could be achieved by use of SSL/TLS for example.</p>
+ <p>Integrity protection of the access-control policy statements may be
+ required. This could be achieved by use of SSL/TLS, for example.</p>
<h2 id="syntax">Syntax</h2>
@@ -430,28 +431,28 @@
in RFC 3490. [<cite><span>RFC3986</span></cite>]
[<cite><span>RFC3490</span></cite>]</p>
- <p>In addition to matching the above EBNF the <span><code>ToASCII</code>
+ <p>In addition to matching the above EBNF, the <span><code>ToASCII</code>
algorithm</span> <em class="ct">must</em> apply successfully (without
errors) to each <code>label</code> component of the <code>subdomain</code>
(if any) from the access item.</p>
<div class="note">
- <p>Since HTTP syntax does not allow Unicode <code>domain</code> has to be
+ <p>Since HTTP syntax does not allow Unicode, <code>domain</code> has to be
written within the ASCII range resorting to the punycode syntax when
necessary.</p>
- <p>If the <code>scheme</code> omitted it will match any
+ <p>If the <code>scheme</code> is omitted, it will match any
<code>scheme</code> from the <span>referrer root URI</span>. If
- <code>port-pattern</code> is omitted the <code>port</code> for the access
+ <code>port-pattern</code> is omitted, the <code>port</code> for the access
item will be the default <code>port</code> for the <code>scheme</code> of
the access item, or the default <code>port</code> of the
- <code>scheme</code> of the referrer root URI if the access item did not
- include a <code>scheme</code>. If <code>port-pattern</code> is
- <code>*</code> it will match any <code>port</code>.</p>
+ <code>scheme</code> of the referrer root URI (if the access item did not
+ include a <code>scheme</code>). If <code>port-pattern</code> is
+ <code>*</code>, it will match any <code>port</code>.</p>
- <p>When <code>*</code> is used as part of <code>domain-pattern</code> it
+ <p>When <code>*</code> is used as part of <code>domain-pattern</code>, it
matches any number of internationalized labels before
- <code>domain</code>. If just <code>domain</code> is used it will match
+ <code>domain</code>. If just <code>domain</code> is used, it will match
itself and any number of internationalized labels before
<code>domain</code>.</p>
</div>
@@ -520,7 +521,7 @@
<p class="note">The syntax of access items when used in the
<code title="">Access-Control</code> HTTP header is restricted to
internationalized domain names to which the ToASCII algorithm has been
- applied as HTTP does not support Unicode.</p>
+ applied (as HTTP does not support Unicode).</p>
<p><code>LWS</code> and <code>Method</code> are used as defined by RFC
2616. The <code>pattern</code> production above <em class="ct">must</em>
@@ -528,12 +529,12 @@
everywhere else. [<cite><span>RFC2616</span></cite>]</p>
<p>In case resources on a domain are not all in the control of a single
- person "deny" rules can be used by authors to deny read access from
+ person, "deny" rules can be used by authors to deny read access from
external resources to the entire domain. Read access from other domains is
by default disallowed but individual resources on the domain could have
<code><?access-control?></code> processing instructions specified which
can allow access from other domains. Although files can contain processing
- instructions, HTTP headers can be set across an entire server
+ instructions, HTTP headers can be set across an entire server,
making them far more effective. The "exclude" clause can be used to list
exclusions to these "deny" rules.</p>
@@ -541,26 +542,26 @@
as long as those domains don't match any of the patterns listed in
"exclude".</p>
- <p>For cross-site non-<code>GET</code> access requests the server to which
- the request is made can list which non-<code>GET</code> methods are allowed
+ <p>For cross-site non-<code>GET</code> access requests, the server to which
+ the request is made can list which non-<code>GET</code> methods are allowed,
using a comma-separated list after the "method" rule.
<div class="example">
<pre><code>Access-Control: allow <*.example.org> exclude <*.public.example.org>
Access-Control: allow <webmaster.public.example.org></code></pre>
- <p>Means that every subdomain of <code>example.org</code> can access the
- resource including <code>webmaster.public.example.org</code>, but with the
+ <p>The above example indicates that every subdomain of <code>example.org</code> can access the
+ resource, including <code>webmaster.public.example.org</code>, but with the
exclusion of all other subdomains of <code>public.example.org</code>.</p>
<pre><code>Access-Control: allow <example.org></code></pre>
- <p>Means that <code>example.org</code> and all its subdomains can access
+ <p>The above example means that <code>example.org</code> and all its subdomains can access
the resource.</p>
<pre><code>Access-Control: allow <example.org> <example.invalid> method POST PUT</code></pre>
- <p>Means that <code>example.org</code> and <code>example.invalid</code>
+ <p>The above example means that <code>example.org</code> and <code>example.invalid</code>
can access the resource and perform <code>POST</code> and
<code>PUT</code> requests.</p>
</div>
@@ -571,20 +572,20 @@
<p>XML resources <em class="ct">may</em> include one or more<!--may implies zero-->
<code><?access-control?></code> processing instructions within the XML
- Prolog to indicate, if the <span>access control read policy</span>
- applies, from which domains their content can be accessed.
+ Prolog, to indicate (if the <span>access-control read policy</span>
+ applies) from which domains their content can be accessed.
[<cite><span>XML</span></cite>]</p>
- <p>The processing instruction takes three pseudo-attributes which each
+ <p>The processing instruction takes three pseudo-attributes, which in turn each
take a <span>space-separated list</span> of
- <span title="access item">access items</span> and one psuedo-attribute
+ <span title="access item">access items</span>, and one pseudo-attribute
which takes a <span>space-separated list</span> of HTTP methods. These
pseudo-attributes are <code>allow</code>, <code>deny</code>,
- <code>exclude</code>, and <code>method</code> respectively. Either the
+ <code>exclude</code>, and <code>method</code>, respectively. Either the
<code>allow</code> or <code>deny</code> pseudo-attribute
<em class="ct">must</em> be specified. <code>allow</code> and
<code>deny</code> <em class="ct">must not</em> be specified at the same
- time. If the <code>deny</code> psuedo-attribute is specified the
+ time. If the <code>deny</code> pseudo-attribute is specified, the
<code>method</code> attribute <em class="ct">must not</em> be
specified.</p>
@@ -617,9 +618,9 @@
<p>The
<dfn id="referer-root-header" title="Referer-Root"><code>Referer-Root</code>
- (sic)</dfn> request HTTP header helps servers knowing where the request
- originates in case the <code>Referer</code> header is not included in the
- request. It also indicates that the request is a cross-site access request.
+ (sic)</dfn> request HTTP header helps servers know where the request
+ originates from (in case the <code>Referer</code> header is not included in the
+ request). It also indicates that the request is a cross-site access request.
The header <em class="ct">must</em> match the following EBNF:</p>
<pre>Referer-Root ::= "Referer-Root" ":" <span>referrer root URI</span></pre>
@@ -630,7 +631,7 @@
request HTTP header informs the server that the client is making an
authorization request and will make a
subsequent request to the same URI using a different method specified in
- the <code>Method-Check</code> HTTP header if that is allowed by the server
+ the <code>Method-Check</code> HTTP header, if that is allowed by the server
per the semantics of authorization requests.
The <code>Method-Check</code> HTTP header <em class="ct">must</em> match the
following EBNF:</p>
@@ -645,7 +646,7 @@
<p>The
<dfn id="method-check-expires-header"><code>Method-Check-Expires</code></dfn>
HTTP response header indicates how long the results of an
- authorization request can be cached in an authorization request cache. The
+ authorization request can be cached in an authorization-request cache. The
<code>Method-Check-Expires</code> HTTP header <em class="ct">must</em>
match the following EBNF:</p>
@@ -658,18 +659,18 @@
<h2 id="processing-model">Processing Model</h2>
<p>The various subsections below describe the various processing models
- user agents and specifications have to implement.</p>
+ that user agents and specifications have to implement.</p>
<h3>Cross-site Access Request</h3>
<p>A <dfn id="cross-site-access-request">cross-site access request</dfn>
takes the parameters <var>request URI</var> and <var>request method</var>.
- If <var>request method</var> is equal to <code>GET</code> the user agent
+ If <var>request method</var> is equal to <code>GET</code>, the user agent
<em class="ct">must</em> follow the <span>cross-site <code>GET</code>
- access request</span> algorithm. Otherwise the <span>cross-site
+ access request</span> algorithm. Otherwise, it must follow the <span>cross-site
non-<code>GET</code> access request</span> algorithm.</p>
- <p>These algorithms have shared return values that specifications can use
+ <p>Those algorithms have shared return values that specifications can use
to instruct user agents what to do.
The <dfn id="return-flag-status" title="status flag">status return flag</dfn>
@@ -680,7 +681,7 @@
user aborted the request.
The <dfn id="return-flag-uri" title="uri flag">uri return flag</dfn> is
- used when the status return flag is "same-origin" to indicate
+ used when the status return flag is "same-origin", to indicate
the URI which the specification can use for a subsequent same-origin
request.</p>
@@ -691,22 +692,22 @@
<p>The <dfn id="referrer-root-uri">referrer root URI</dfn> is the
<code>scheme</code> followed by <code>://</code>, followed by the
- <code>domain</code> without any trailing U+002E (<code>.</code>),if any,
+ <code>domain</code> without any trailing U+002E (<code>.</code>), if any,
where each part of the <code>domain</code> has had the
<span><code>ToASCII</code> algorithm</span> applied, followed by
<code>:</code>, followed by the <code>port</code> (even if it is the
default port for the scheme) of the source of the request. If the resource
- does not have a host-based authority (<code>data:</code> URI scheme for
- instance) the referrer root URI is "null".</p>
+ does not have a host-based authority (<code>data:</code> URI scheme, for
+ instance), the referrer root URI is "null".</p>
<p>Specifications using <span title="cross-site access request">cross-site
access requests</span> <em class="ct">must</em> define the source of the
request for the <span>referrer root URI</span>.
<span class="note">Due to the way the origin for protocols is retrieved in
- different ways it is not possible to define this in a generic
+ different ways, it is not possible to define this in a generic
way.</span></p>
- <p>While following the requirements for cross-site access requests user
+ <p>While following the requirements for cross-site access requests, user
agents <em class="ct">must</em> ensure that each request has a
<code>Referer-Root</code> HTTP request header set, with the value set to
<span>referrer root URI</span>. This includes requests as a result of a
@@ -756,8 +757,8 @@
<dt>Otherwise
<dd>
- <p>Perform an <span>access control check</span> using <code>GET</code> as
- method. If it returns "fail" terminate this
+ <p>Perform an <span>access-control check</span> using <code>GET</code> as
+ method. If it returns "fail", terminate this
algorithm and return with the <span>status flag</span> set
to "network". Otherwise, if it returns "pass", terminate this
algorithm and return with the <span>status flag</span> set
@@ -774,7 +775,7 @@
that consists of a set of entries. Each entry has a <b>key</b>, <b>list of
methods</b>, and an <b>expiry date</b>. Entries <em class="ct">must</em>
be removed when the current time exceeds the time specified by the
- <b>expiry date</b> field. Besides expiring entries are added and removed
+ <b>expiry date</b> field. Besides expiring, entries are added and removed
per the algorithms below. They are added and removed in such a way that
there can never be duplicate items in the cache.</p>
@@ -804,7 +805,7 @@
<p>If there is an entry in the <span>authorization request cache</span>
where the <b>key</b> matches the (<var>origin</var>, <var>current
request URI</var>) tuple and the <var>request method</var> is in the
- <b>list of methods</b> proceed to the next step.</p>
+ <b>list of methods</b>, proceed to the next step.</p>
<p>Otherwise, <span>remove the cache entry</span>, if any, and then make
an <dfn id="authorization-request">authorization request</dfn>, by
@@ -841,8 +842,8 @@
<dt>Otherwise
<dd>
- <p>Perform an <span>access control check</span> using the
- <var>request method</var> as method . If it returns "fail" terminate
+ <p>Perform an <span>access-control check</span> using the
+ <var>request method</var> as method. If it returns "fail", terminate
this algorithm and return with the <span>status flag</span> set to "network". Otherwise, if
it returns "pass" and a "method list", add an entry to the
<span>authorization request cache</span> with as <b>key</b> the
@@ -850,12 +851,12 @@
<b>list of methods</b> the "method list" return value, and as expiry
date the value of the <code>Method-Check-Expires</code> HTTP
response header, if any. If there is no
- <code>Method-Check-Expires</code> HTTP response header the user
+ <code>Method-Check-Expires</code> HTTP response header, the user
agent <em class="ct">may</em> chose to nevertheless cache the entry
for a short period of time or not store a cache entry at all. If
- there is a <code>Method-Check-Expires</code> HTTP response headers
+ there is a <code>Method-Check-Expires</code> HTTP response header
that can be successfully parsed and the current time exceeds the
- time specified by the header <span>remove the cache entry</span>.
+ time specified by the header, <span>remove the cache entry</span>.
</dl>
</ol>
@@ -882,8 +883,8 @@
<dt>Otherwise</dt>
- <dd><p>Perform an <span>access control check</span> using the
- <var>request method</var> as method. If it returns "fail" <span>remove
+ <dd><p>Perform an <span>access-control check</span> using the
+ <var>request method</var> as method. If it returns "fail", <span>remove
the cache entry</span>, then terminate this algorithm, and return with
the <span>status flag</span> set to "network". Otherwise, if it returns
"pass", terminate this algorithm and return with the <span>status
@@ -900,7 +901,7 @@
<p>The <dfn>generic redirect steps</dfn> are as follows:</p>
<p>If the new URI scheme is not supported, infinite loop precautions are
- violated, or something else went wrong terminate the algorithm that
+ violated, or something else went wrong, terminate the algorithm that
invoked this set of steps and return with the <span>status flag</span> set
to "network".</p>
@@ -909,19 +910,19 @@
<ol>
<li>If the <var>current request URI</var> and <var>origin</var> are
- <span>same-origin</span> terminate the algorithm that invoked this set of
+ <span>same-origin</span>, terminate the algorithm that invoked this set of
steps and return with the <span>uri flag</span> set to the <var>current
- request URI</var> and the <span>status flag</span> to "same-origin".</li>
+ request URI</var> and the <span>status flag</span> set to "same-origin".</li>
<li>Otherwise, transparently follow the redirect while observing the
set of <i>request rules</i>.</li>
</ol>
- <p>Whenever the <dfn>generic abort steps</dfn> are applied terminate the
+ <p>Whenever the <dfn>generic abort steps</dfn> are applied, terminate the
algorithm that invoked this set of steps and return with the <span>status
flag</span> set to "abort".</p>
- <p>Whenever the <dfn>generic network error steps</dfn> are applied
+ <p>Whenever the <dfn>generic network error steps</dfn> are applied,
terminate the algorithm that invoked this set of steps and return with the
<span>status flag</span> set to "network".</p>
@@ -930,32 +931,32 @@
(<var>origin</var>, <var>current request URI</var>).</p>
- <h3>Access Control Check</h3>
+ <h3>Access-Control Check</h3>
- <h4>Access Control Check Algorithm</h4>
+ <h4>Access-Control Check Algorithm</h4>
- <p>When a user agents has to make an <dfn id="access-control-check">access
- control check</dfn> for a particular resource it <em class="ct">must</em>
+ <p>When a user agent has to make an <dfn id="access-control-check">access
+ control check</dfn> for a particular resource, it <em class="ct">must</em>
then associate the following with that resource:</p>
<ul>
- <li><p>An unordered, initially empty, <dfn>HTTP access control allow
- list</dfn> of which each list item contains a <span>match list</span>,
+ <li><p>An unordered, initially empty, <dfn>HTTP access-control allow
+ list</dfn>, of which each list item contains a <span>match list</span>,
an <span>exclude list</span>, and <span>method list</span>.</p></li>
- <li><p>An unordered, initially empty, <dfn>HTTP access control deny
- list</dfn> of which each list item contains a <span>match list</span> and
+ <li><p>An unordered, initially empty, <dfn>HTTP access-control deny
+ list</dfn>, of which each list item contains a <span>match list</span> and
an <span>exclude list</span>.</p></li>
- <li><p>An unordered, initially empty, <dfn>PI access control allow list</dfn>
+ <li><p>An unordered, initially empty, <dfn>PI access-control allow list</dfn>,
of which each list item contains a <span>match list</span>, an
<span>exclude list</span>, and a <span>method list</span>.</p></li>
- <li><p>An unordered, initially empty, <dfn>PI access control deny list</dfn>
+ <li><p>An unordered, initially empty, <dfn>PI access-control deny list</dfn>,
of which each list item contains a <span>match list</span> and an
<span>exclude list</span>.</p></li>
- <li><p>An <dfn>allow access flag</dfn> which is used in the algorithms to
+ <li><p>An <dfn>allow access flag</dfn>, which is used in the algorithms to
determine at certain points whether access will be granted. The flag has
two values: "true" and "false". Its initial value is "false".</p></li>
</ul>
@@ -966,42 +967,42 @@
lists are guaranteed to be non-empty and the exclude lists can be empty.
The <dfn title="method list" id="method-list">method lists</dfn> are
unordered lists of HTTP methods. They can be empty and are only used in an
- access control check as the result of an authorization request.</p>
+ access-control check as the result of an authorization request.</p>
- <p>If an HTTP method name was passed as parameter to the access control
- check algorithm that will be the <var>request method</var>. If none was
- passed <var>request method</var> is <code>GET</code>. In addition there is
+ <p>If an HTTP method name was passed as parameter to the access-control
+ check algorithm, that will be the <var>request method</var>. If none was
+ passed, <var>request method</var> is <code>GET</code>. In addition, there is
the <var>temp method list</var> that will eventually be used for the
<span>authorization request cache</span> entry.</p>
<p>After associating the aforementioned lists and when all HTTP headers
- have been received the user agent <em class="ct">must</em> run the
+ have been received, the user agent <em class="ct">must</em> run the
following algorithm (unless stated otherwise):</p>
<ol>
<li>
<p>Parse the <code>Access-Control</code> headers. If any value does not
- conform to the syntax required terminate the algorithm and return
+ conform to the syntax required, terminate the algorithm and return
"fail". Otherwise, if parsed successfully, then for each rule run the
following steps:</p>
<ol>
- <li><p>If <code>rule</code> is <code>rule-allow</code> append a new
- list item to the <span>HTTP access control allow list</span> where the
+ <li><p>If <code>rule</code> is <code>rule-allow</code>, append a new
+ list item to the <span>HTTP access-control allow list</span>, where the
<span>match list</span> is constructed of each <span>access item</span>
following <code>"allow"</code>, the <span>exclude list</span> of each
<span>access item</span> following <code>"exclude"</code>, and the
<span>method list</span> of each HTTP method following
<code>"method"</code>. If <code>"exclude"</code> or
- <code>"method"</code> is not present their respective list will be
+ <code>"method"</code> is not present, their respective list will be
empty.</p></li>
- <li><p>If <code>rule</code> is <code>rule-deny</code> append a new list
- item to the <span>HTTP access control deny list</span> where the
+ <li><p>If <code>rule</code> is <code>rule-deny</code>, append a new list
+ item to the <span>HTTP access-control deny list</span>, where the
<span>match list</span> is constructed of each <span>access item</span>
following <code>"deny"</code> and the <span>exclude list</span> of each
<span>access item</span> following <code>"exclude"</code>. If
- <code>"exclude"</code> is not present the exclude list will be
+ <code>"exclude"</code> is not present, the exclude list will be
empty.</p></li>
</ol>
</li>
@@ -1010,19 +1011,19 @@
control deny list</span>.</p></li>
<li><p>Then run the <span>allow list check</span> on the <span>HTTP
- access control allow list</span>.</p></li>
+ access-control allow list</span>.</p></li>
<li><p>If the requested resource has an <span>XML MIME type</span> and a
- non-empty entity body go to the next step. Otherwise, if the <span>allow
- access flag</span> is "false" then terminate the algorithm and return
- "fail". If the <span>allow access flag</span> is "true" then terminate
+ non-empty entity body, go to the next step. Otherwise, if the <span>allow
+ access flag</span> is "false", then terminate the algorithm and return
+ "fail". If the <span>allow-access flag</span> is "true", then terminate
the algorithm, return "pass", and return the <var>temp method
list</var>.</p></li>
<li>
- <p>Parse the resource as an XML document using a streaming XML parser
+ <p>Parse the resource as an XML document using a streaming XML parser,
following the rules set forth in the XML specification up to but
- <em>not</em> including the root element start tag. Then process the
+ <em>not</em> including the root-element start tag. Then process the
encountered <code><?access-control?></code> processing instructions
(if any). [<cite><span>XML</span></cite>]</p>
@@ -1065,7 +1066,7 @@
the <code>exclude</code> pseudo-attribute value. If any obtained value
does not match the <span>access item</span> syntax or if no value was
obtained, then terminate the overall algorithm and return "fail". If
- there is no such pseudo-attribute let <var>temp exclude list</var> be
+ there is no such pseudo-attribute, let <var>temp exclude list</var> be
empty.</p></li>
<li><p>If there is a <code>method</code> pseudo-attribute let
@@ -1074,17 +1075,17 @@
the <code>method</code> pseudo-attribute value. If any obtained value
does not match the HTTP method syntax or if no value was obtained, then
terminate the overall algorithm and return "fail". If there is no such
- pseudo-attribute let <var>temp method list</var> be empty.</p></li>
+ pseudo-attribute, let <var>temp method list</var> be empty.</p></li>
<li>
- <p>If there is an <code>allow</code> pseudo-attribute append a new
- list item to the <span>PI access control allow list</span> where the
+ <p>If there is an <code>allow</code> pseudo-attribute, append a new
+ list item to the <span>PI access-control allow list</span>, where the
<span>match list</span> is <var>temp match list</var>, the
<span>exclude list</span> is <var>temp exclude list</var>, and the
<span>method list</span> is <var>temp method list</var>.</p>
- <p>Otherwise, there is a <code>deny</code> psuedo-attribute. Append a new
- list item to the <span>PI access control deny list</span> where the
+ <p>Otherwise, there is a <code>deny</code> pseudo-attribute. Append a new
+ list item to the <span>PI access-control deny list</span>, where the
<span>match list</span> is <var>temp match list</var> and the
<span>exclude list</span> is <var>temp exclude list</var>.</p>
</li>
@@ -1097,8 +1098,8 @@
<li><p>Then run the <span>allow list check</span> on the <span>PI access
control allow list</span>.</p></li>
- <li><p>If the <span>allow access flag</span> is "false" then return
- "fail". Otherwise, if the <span>allow access flag</span> is "true", then
+ <li><p>If the <span>allow-access flag</span> is "false", then return
+ "fail". Otherwise, if the <span>allow-access flag</span> is "true", then
return "pass" and return the <var>temp method list</var>.</li>
</ol>
@@ -1110,18 +1111,18 @@
algorithms defined in this section.</p>
<p>The <dfn>deny list check</dfn> algorithm takes a list of items
- consisting of match and exclude lists. For each item in the list run the
+ consisting of match and exclude lists. For each item in the list, run the
following steps:</p>
<ol>
<li><p>If there is no <span>match</span> for any <span>access item</span>
from the <span>match list</span> against the <span>referrer root
- URI</span> process the next list item. If there is no next list item,
+ URI</span>, process the next list item. If there is no next list item,
then go to the next step in the overall set of steps.</p></li>
<li><p>If the <span>exclude list</span> is non-empty and there is a
<span>match</span> for any <span>access item</span> from the
- <span>exclude list</span> against the <span>referrer root URI</span>
+ <span>exclude list</span> against the <span>referrer root URI</span>,
process the next list item. If there is no next list item, then go to the
next step in the overall set of steps.</p></li>
@@ -1129,34 +1130,34 @@
</ol>
<p>The <dfn>allow list check</dfn> algorithm takes a list of items
- consisting of match, exclude, and method lists. For each item in the list
+ consisting of match, exclude, and method lists. For each item in the list,
run the following steps:</p>
<ol>
<li><p>If there is no <span>match</span> for any <span>access item</span>
from the <span>match list</span> against the <span>referrer root
- URI</span> process the next list item. If there is no next list item,
+ URI</span>, process the next list item. If there is no next list item,
then go to the next step in the overall set of steps.</p></li>
<li><p>If the <span>exclude list</span> is non-empty and there is a
<span>match</span> for any <span>access item</span> from the
- <span>exclude list</span> against the <span>referrer root URI</span>
+ <span>exclude list</span> against the <span>referrer root URI</span>,
process the next list item. If there is no next list item, then go to the
next step in the overall set of steps.</p></li>
<li>
<p>If the <var>request method</var> is not <code>GET</code> and the
- <var>request method</var> is not in the <span>method list</span> process
+ <var>request method</var> is not in the <span>method list</span>, process
the next list item. If there is no next list item, then go to the next
step in the overall set of steps.</p>
<p class="note">HTTP method comparison is case-sensitive.</p>
</li>
- <li><p>If the <var>request method</var> is not <code>GET</code> append
+ <li><p>If the <var>request method</var> is not <code>GET</code>, append
the items from <span>method list</span> to <var>temp method
list</var>.</p></li>
- <li><p>Set the <span>allow access flag</span> to "true".</p></li>
+ <li><p>Set the <span>allow-access flag</span> to "true".</p></li>
<li><p>If the <var>request method</var> is <code>GET</code>, then go to
the next step in the overall set of steps.</p></li>
@@ -1169,7 +1170,7 @@
</ol>
- <h3>Access Item Check</h3>
+ <h3>Access-Item Check</h3>
<p>The algorithm described below determines whether there is a match
between a <span>referrer root URI</span>
@@ -1197,20 +1198,20 @@
</div>
<p>To determine whether a <span>referrer root URI</span> and an <span>access
- item</span> <dfn id="match">match</dfn> user agents <em class="ct">must</em>
+ item</span> <dfn id="match">match</dfn>, user agents <em class="ct">must</em>
run the following algorithm:</p>
<ol>
<li><p>Let <var>origin</var> be <span>referrer root URI</span> and
<var>item</var> be <span>access item</span>.</p></li>
- <li><p>If <var>item</var> is a single U+002A (<code>*</code>)
+ <li><p>If <var>item</var> is a single U+002A (<code>*</code>),
there is a match. Terminate this algorithm.</p></li>
- <li><p>If <var>origin</var> is "null" there is no match.
+ <li><p>If <var>origin</var> is "null", there is no match.
Terminate this algorithm.</p></li>
- <li><p>If <var>item</var> does not have a <code>port-pattern</code> let
+ <li><p>If <var>item</var> does not have a <code>port-pattern</code>, let
the <code>port</code> of <var>item</var> be the default <code>port</code>
for the <code>scheme</code> of <var>item</var> or, if <var>item</var>
does not have a <code>scheme</code>, let it be the default
@@ -1219,23 +1220,23 @@
<li><p>If <var>item</var> has a <code>scheme</code> and it does
not <span title="case-insensitive match">case-insensitively match</span>
- the <code>scheme</code> from <var>origin</var> there is no match.
+ the <code>scheme</code> from <var>origin</var>, there is no match.
Terminate this algorithm.</p></li>
<li><p>Remove the <code>scheme</code> from <var>item</var> (if it has one
- specified) and <var>origin</var> including the <code>://</code> sequence
+ specified) and <var>origin</var>, including the <code>://</code> sequence
following it.</p></li>
<li><p>If the <code>port</code> from <var>item</var> does not match the
- <code>port</code> from <var>origin</var> and is not <code>*</code> there
+ <code>port</code> from <var>origin</var> and is not <code>*</code>, there
is no match. Terminate this algorithm.</p></li>
<li><p>Remove the <code>port</code> from <var>item</var> and
- <var>origin</var> including the U+003A (<code>:</code>) preceding
+ <var>origin</var>, including the U+003A (<code>:</code>) preceding
it.</p></li>
<li><p>If item <var>item</var> has a single U+002E
- (<code>.</code>) as last character remove that character from
+ (<code>.</code>) as last character, remove that character from
<var>item</var>.</p></li>
<li><p>Let <var>origin list</var> be <var>origin</var>
@@ -1267,12 +1268,12 @@
<li>
<p>If <var>origin label</var> does not
<span title="case-insensitive match">case-insensitively match</span>
- <var>item label</var> there is no match (terminate the overall
+ <var>item label</var>, there is no match (terminate the overall
algorithm).</p>
<p>Otherwise, apply these set of steps to the next list item of both
<var>origin list</var> and <var>item list</var>. If
- the <var>origin list</var> has no next list item there is no
+ the <var>origin list</var> has no next list item, there is no
match (terminate the overall algorithm). If the
<var>item list</var> has no next list item, then go to the next
step in the overall set of steps.</p></li>
@@ -1436,7 +1437,7 @@
<li>
<p>An XBL binding allows full access to the document it is bound to and
therefore cross-site XBL usage is prevented. Access Control enables
- cross-site XBL bindings. If the user is authenticed with the server that
+ cross-site XBL bindings. If the user is authenticated with the server that
hosts the XBL widget it is possible to have a user-specific cross-site
bindings.
@@ -1464,7 +1465,7 @@
<dt>Why is there a second check for non-<code>GET</code> requests?
<dd>
- <p>For non-GET requests two <span title="access control check">access
+ <p>For non-GET requests two <span title="access-control check">access
control checks</span> are performed. Initially a "permission to make the
request" check is done on the response to the <span>authorization
request</span>. And then a "permission to read" check is done on the
@@ -1626,7 +1627,7 @@
for their contributions to this specification.</p>
- <p>Special thanks to Brad Porter, Matt Oshry and R. Auburn who helped
+ <p>Special thanks to Brad Porter, Matt Oshry and R. Auburn, who all helped
editing earlier versions of this document.</p>
</body>
</html>
--
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/
Received on Wednesday, 23 January 2008 14:05:02 UTC