On 16/06/2009, at 12:16 AM, Anne van Kesteren wrote:
On Mon, 15 Jun 2009 04:36:28 +0200, Mark Nottingham <[email protected]>
wrote:
Content providers wanted the flexbility of not having to list
every
header in advance. Both so debugging headers and such would not
have
to be exposed and to reduce the payload.
Which content providers? How much extra payload do you really
expect
this to be?
I believe Google, Microsoft, Mozilla, and SitePen.
I don't know how much payload would be saved, but that was not the
only
reason.
The others being?
Not exposing debugging headers.
Seems like an odd justification, but OK.
Some prior discussion on response headers:
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg58
So, the crux of the motivation seems to be Ian's:
I don't think we should change this without a better reason.
There's no
reason to believe that some servers don't have information in the
headers that shouldn't be seen by third-parties, and it's the kind
of
thing that would be really easy to miss when securing a page for
third-party access.
It seems odd to me that you're willing to expose all of the data in
the
response, but almost none of the metadata (headers). Taking a quick
look
through the message header registry, a number of candidates that
would
be useful -- if you allowed them -- come up, including: [...]
Note that many of these are critical to understanding the message,
and
disallowing many others will disallow many applications.
For example, [...]
This is not a complete list; adding these headers to your whitelist
will
not resolve this issue.
If this proofs to be a big problem in practice we can let the list
be extended using a response header that lists all headers the
server is willing to share. This could be a CORS2 feature.
IMO this is a showstopper for CORS1. Do the right thing: expand the
list of headers allowed and add this functionality now.
Here's a thread on request headers:
http://lists.w3.org/Archives/Public/public-appformats/2008Feb/thread.html#msg168
Similar concerns seem to apply here. You mention theoretical attacks/
risks a lot, and people who disagree are asked to prove a negative
-- an
unrealistically high bar.
It does not follow that we then have to simply allow it.
Also note that _with_ a preflight request which will be necessary
for many requests anyway you _can_ include almost any header you
want apart from the ones that are on the XMLHttpRequest blacklist.
*grumble* OK.
http://www.w3.org/2005/06/tracker/waf/issues/22
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg303
Where is the sentence that the resolution of that issue refers to?
Access-Control-Policy-Path was not found to be workable solution in
the end
http://www.w3.org/2008/webapps/track/issues/12
unfortunately.
Indeed. Were other approaches to applying policy to multiple URLs
considered?
Probably "resource processing model..."
I started making changes in that direction and it did not make a
whole
lot of sense. E.g. how would you rephrase "In response to a simple
cross-origin request or actual request the server indicates
whether or
not to share the resource."?
"In response to either an actual request or a simple cross-origin
request, the resource indicates whether or not to share the
response."
although in this particular case, "... the server indicates whether
or
not to share the response" would work as well (since it's
unambiguous).
The distinction is more important when talking about scoping -- e.g.,
does a decision apply to a single response, all responses from a
resource (as identified by a URI), or all responses from a server.
I made the changes here now. I'd appreciate if you could go over it
to see it is ok.
Had a look through the current editors' draft -- looks good to me.
A few nits:
In 5.1, "In case the resource has been relocated the resource
indicates whether to share the new URL of the resource."
is wordy; try
"If the resource has been relocated, it indicates whether to share
its new URL."
In 6.2, throughout this section, there are statements like "If the
resource includes zero or more..." Instead of "resource" I think
"response" would be more appropriate, but I may be reading it out of
context.
In 7.3, "The contents of the resource..." --> "The contents of the
response..."
Cheers,
--
Mark Nottingham http://www.mnot.net/
