Hi guys,
Recently mozilla received some input with regards to some aspects of the
access-control spec, in addition to the concern that I brought up to
hixie and which he posted about in the "Opting into cookies" thread.
I will address these new concerns in two emails, this one and one I'm
posting in a few minutes.
There is a concern with the fact that when a server administrator
enables cross-site access to unsafe methods (POST/DELETE etc) using the
access-control spec he has to be able to handle almost all possible HTTP
methods, as well as all possible http-headers. This is a problem for two
reasons.
First of all it is very possible that the server itself, or the scripts
running on the server, performs actions that the server administrator is
not aware of. For example an administrator might not realize that the
server supports the PUT action such that other sites can't just POST to
a CGI script, but also replace the script using PUT.
Second, even if the administrator is aware of the server performing a
harmful action for certain headers or methods, it can be very hard to
change this. The current spec has an all-or-nothing approach. To enable
cross-site POST you also are forced to deal with all other methods,
weather you want them or not.
To address this I propose that we add two new headers:
Access-Control-Extra-Headers:
This header contains a whitespace separated list of headers that the
servers wants to allow the requesting site to set. This can be both
standard headers, as well as custom headers.
Access-Control-Methods:
This header contains a whitespace separated list of HTTP methods that
the server wants to allow the requesting site to use. This can be both
standard methods, as well as custom methods.
Both these lists will be stored in the "method check result cache" (btw,
that name sounds odd since it's not a method-check, but rather an
access-check).
Note that this proposal is much simpler than the old syntax we used to
have where the methods were listed as part of the Access-Control header
since the syntax is much simpler, and neither header is part of the key
to the "method check result cache" but rather stored as values in it.
This will significantly reduce the risk that a server operator opts in
to something which isn't secure. First of all because you opt in to much
less (just a short whitelist of headers/methods rather than the whole
possible space), and second because you are unlikely to opt in to
something which you don't know how it works.
/ Jonas
