not include the
path) and could therefore be used for Access Control but also to
prevent CSRF.
Incidentally, +1 to Origin - for two reasons:
(a) it might indeed turn out to be more generally useful
(b) it's much less of a mouthful than Access-Control-Origin
--
Thomas Roessler, W3C [EMAIL
that a failure of the server
identity check (section 3.1 of RFC 2818) MUST cause the client to
terminate the connection.
(RFC 2818 gives a choice of either giving the user a choice or
terminating the connection.)
--
Thomas Roessler, W3C [EMAIL PROTECTED]
for the user
interaction.
To the best of our knowledge, most browser prompt the user, and
throw an exception if the user cancels the connection.
(ACTION-444 in Web Security Context.)
Regards,
--
Thomas Roessler, W3C [EMAIL PROTECTED]
to manipulate
the data, even though the user is allowed to see the data.
See this message:
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0290.html
... for a more detailed discussion of that topic, and some links.
Regards,
--
Thomas Roessler, W3C [EMAIL PROTECTED]
of the three APIs, because it
has a straight-forward programming model.
Incidentally, the same considerations apply to postMessage; see:
http://lists.w3.org/Archives/Public/public-html-comments/2008Apr/.html
Regards,
--
Thomas Roessler, W3C [EMAIL PROTECTED]
think that new cross-origin APIs that
just return a string (but are clearly intended for structured
data) should be standardized (or shipped) given the experience
that's available.
Regards,
--
Thomas Roessler, W3C [EMAIL PROTECTED]
and possibilities for
insecurities down the road.
I'd rather we deal with the added attack surface due to being able
to POST properly labelled XML content than introducing another
divergence into how HTTP headers are interpreted by Web
applications.
--
Thomas Roessler, W3C [EMAIL PROTECTED]
