Treatment of empty-valued Access-Control-Request-Headers

[sof]

Following steps 3-5 of https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 , a CORS-preflight request will always include a "Access-Control-Request-Headers" mapping, even if |headers| is empty. (Which is consistent with https://fetch.spec.whatwg.org/#http-new-header-syntax)

This represents a change from earlier treatments of this header value for preflights ( https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 ), which left it out if the preflighted requests only had CORS-safelisted headers (nee author request headers)... even though it was spec'ed as legal to send an empty value.

This is change in behaviour is causing some downstream services to fail upon encountering such an empty-valued header, see https://crbug.com/633729 . Might it be worth considering limiting ACRH to non-empty values?

[annevk]

Yeah, given that it causes issues we should definitely change it back. I don't think this change was even intentional. Do you prefer your name with "o" or "ø" by the way? I've seen you use both forms.

[sof]

Thanks for quickly following up, appreciated. I'll re-sync Blink, the crbug issue suggests that it is the only one that had changed.

(Passport uses ø, only preference is not having encoding issues :) )