More wildcards in CORS when used without credentials

[annevk]

Fixes #251 and fixes #252.

[annevk]

@tyoshino review appreciated. @roryhewitt, @craigfrancis, @mozfreddyb, you might be interested in reviewing too. @sicking, I included your suggestion around Authorization.

[MichaelKohler]

I highly suspect this to be a typo and it should read "wildcard"?

[annevk]

I thought a bit about this and I think one thing we should probably change is to make the CORS-preflight cache support wildcards directly. That could have a pretty dramatic impact on reducing chattiness.

[roryhewitt]

@annevk that would be nice. +1 from me.

[roryhewitt]

Shouldn't this be #field-name-or-wildcard (with a leading #?), and also contain the link to the IETF?

[annevk]

It should have the leading #, but since this is not an IETF production this should not link.

[annevk]

I now changed it so that the CORS-preflight cache can store wildcards which should reduce chattiness a whole lot for non-credentialed requests (at the point user agents implement this, of course).

[annevk]

@roryhewitt @tyoshino would you be so kind to look over the latest changes? I think this is ready, but I just want to be sure.

[roryhewitt]

@annevk I think the second example in section 4.2.6 should have the last line changed to something like this:

This is because bar.invalid needs to explicitly share each header by listing their names in the Access-Control-Expose-Headers response header. Alternatively, bar.invalid could have returned Access-Control-Expose-Headers: * which would share all response headers.

Basically showing developers that they can specify Access-Control-Expose-Headers: *.

[annevk]

Ended up writing an extra paragraph.

[roryhewitt]

@annevk Perfect!

[tyoshino]

paragraph not enclosed

[tyoshino]

Sorry for delay.

lgtm but I want to make sure that it's fine that

• a user-agent may end up sending no credential even when credentials mode is set to include
• in such case, the server cannot know that the client is using "credentials mode == include omit" only by inspecting the received request, and therefore it's not safe to use the wildcard.

This means that developers are basically required to coordinate use of the wildcard between client code and server. Right?

[Edited] include -> omit

[annevk]

@tyoshino yeah, I think that coordination has effectively always been required (it also applies to the wildcard case for origin). It might help if we start communicating that more clearly, but that would be a new request header and a separate discussion.

[tyoshino]

ok. lgtm

[annevk]

Thank you (and the others)!

[roryhewitt]

@annevk forgive my ignorance, but I'm not sure how this all goes together...

If these new wildcard values are now in the master branch (and are what I see when I go to https://fetch.spec.whatwg.org/#http-new-header-syntax), does that mean that they are officially supported by all (major) browsers? Or is this just a new version of the Fetch spec, and as browsers add support for them, they will publicize this fact?

[annevk]

@roryhewitt the latter. I wish it were that easy!

[tonyjin]

Also not sure how this all goes together, but I noticed the following two don't match:
https://www.w3.org/TR/cors/#access-control-allow-headers-response-header
https://fetch.spec.whatwg.org/#http-new-header-syntax

Specifically:
Access-Control-Allow-Headers: "Access-Control-Allow-Headers" ":" #field-name (in W3)
Access-Control-Allow-Headers = #field-name-or-wildcard (in Fetch Spec)

As I was writing this I realized the W3 recommendation was published in Jan 2014, so I guess we'll have to wait for a newer version to be published?

Does the latest fetch spec's definition of Access-Control-Allow-Headers supersede the W3 recommendation?

[annevk]

@tonyjin yes it does. W3C's copy of CORS is obsolete and should not be used. Unfortunately they have so far refused to clearly mark it as such.

[roryhewitt]

Hey Tony,

Yes, the fetch spec on WHATWG (including the CORS headers) supersedes the
W3C spec.

Unfortunately, it appears to be a low priority to get this 'publicized' by,
for instance, updating the W3C spec to make it clear.

Note also that, although the latest fetch spec includes wildcards for the
ACAM, ACAH and ACEH headers, I'm not sure whether these special values are
actually supported by any browsers yet...

Perhaps @annevk can comment?

Rory

Sent from my phone - please excuse spelling & brevity...

On Sep 15, 2016 12:34 PM, "Tony Jin" notifications@github.com wrote:

Also not sure how this all goes together, but I noticed the following two
don't match:
https://www.w3.org/TR/cors/#access-control-allow-headers-response-header
https://fetch.spec.whatwg.org/#http-new-header-syntax

Specifically:
Access-Control-Allow-Headers: "Access-Control-Allow-Headers" ":"
#field-name (in W3)
Access-Control-Allow-Headers = #field-name-or-wildcard (in Fetch Spec)

As I was writing this I realized the W3 recommendation was published in
Jan 2014, so I guess we'll have to wait for a newer version to be published?

Does the latest fetch spec's definition of Access-Control-Allow-Headers
supersede the W3 recommendation?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#298 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALBf60j_0OIhrc8xQunqDE1LaTQOZ8v3ks5qqZ2-gaJpZM4IYBHx
.

[tonyjin]

Thanks for clarifying and working on this @annevk & @roryhewitt - I ran into this PR after getting frustrated at adding Access-Control-Allow-Headers: [a bajillion headers] in nginx 🙄