On Tue, 15 Jul 2008 01:02:58 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
Since implementations need answers to various open issues soonish and
I'm leaving on vacation roughly two days from now I'll propose various
solutions here and try to integrate them in drafts later on:
I made the changes to the Access Control for Cross-Site Requests
specification as described below. From discussion it seemed that everyone
could agree to this fortunately. (Although there was some discussion on
whether or not the Access-Control-Allow-Origin value syntax needed
changing.)
HEADER NAMES
Access-Control-Origin -> Access-Control-Allow-Origin
Access-Control-Credentials -> Access-Control-Allow-Credentials
HEADER SYNTAX
Parsing Access-Control-Allow-Origin will have a check to ensure that
<path> is empty. If it is non-empty the network error steps will be
applied. We keep the separate header for credentials to keep the origin
concept orthogonal from the credentials flag.
This changed to become a simple string comparison. Effectively, between
the value of Origin and Access-Control-Allow-Origin.
CROSS-SITE POST
We limit the amount of Content-Type header values people can set for the
simple cross-site POST request to those you can use with HTML forms
today. This list will not become a fixed list until we work out how
Access Control for Cross-Site Requests will work together with HTML5
forms.
I have not yet made this change to XMLHttpRequest Level 2, but the Access
Control specification does support the architecture required for it:
XMLHTTPREQUEST API FLAG
The XMLHttpRequest interface will gain a withCredentials boolean DOM
attribute. The value of that attribute is used during send() and stored
"in memory" when send() is invoked so an event listener dispatched
between send() being invoked and the request happening cannot change it.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
