- From: Emily Stark <estark@google.com>
- Date: Tue, 6 Jun 2017 09:45:42 -0700
- To: httpbis <ietf-http-wg@w3.org>
- Message-ID: <CAPP_2Sa+6eSAChgp8KrzabPJUkMmiKBhWp1dFhS0zOVnXrenLw@mail.gmail.com>
I'm looking for some feedback on https://github.com/httpwg/ http-extensions/issues/356. Expect-CT violation reports are currently specified as POST requests with JSON bodies. When implemented in a web browser, such reports should arguably send CORS preflights, because the content type is not CORS-safelisted (https://www.w3.org/TR/cors/#simple-header). But sending CORS preflights for these requests doesn't really make sense from a web browser architecture perspective: CT compliance is checked as part of certificate verification and connection setup, divorced from the context one needs to send a CORS preflight (such as an Origin header). This is not just a theoretical layering issue; implementing preflights for Expect-CT reports in Chrome would be pretty challenging. I only see two options to resolve this, both of which seem bad to me: a) Leave the reporting part of the spec as it currently is, and leave it up to the UA to decide whether further operations such as CORS preflights are needed for sending reports. This would basically leave it to us in Chrome to decide either that Expect-CT reports should not be subject to CORS restrictions, or that we should not ship reporting. (I'm uncomfortable with this option because it somewhat jeopardizes the only active implementation effort that I know of.) b) The disgusting option: disguise Expect-CT reports as form submissions, which are not subject to CORS preflighting. This would mean the report body is sent as hostname=blah&port=443&... or we could even just send expect-ct-report=<stringified JSON blob>. Thanks, Emily
Received on Tuesday, 6 June 2017 16:46:36 UTC