Re: Issue #356: Form-encode Expect-CT report bodies?

[Martin Thomson <[e-mail]>]

For those who are reading this and eating popcorn, this is probably
worth reading also... <https://github.com/whatwg/fetch/issues/530>

On 9 June 2017 at 16:42, Emily Stark <[e-mail]> wrote:
> As I said in my first message, implementing true preflights would violate
> very core architectural principles in Chrome, and would jeopardize our
> ability to ship an implementation. Maybe there are other implementors who
> would like to chime in to the contrary, but as of now I'm not very inclined
> to specify something that can't realistically be implemented.

I wanted to poke at that a little.  Expect-CT is a header field, sent
by a particular origin.  You store the tuple of origin, the expect CT
mode (none, report, require), and the report URI somewhere.  Then when
you connect to an origin you retrieve any stored tuple and compare
what you get with what you expect.  I don't see how a stack would be
unable to preflight at that point.  It has the information it needs
for a preflight check.

I recognize that a particular piece of software might be constructed
in a way that makes this difficult, but it can't be impossible.

Question: how do you manage the checks when you are using alternative
services?  I expect that you need to store a target origin for the
connection attempt, rather than using the host and port or SNI and
port that you are connecting to.  (This doesn't complicate things
regarding the question at hand, but I don't see any text on this
point.)