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

[Patrick McManus <[e-mail]>]

First, I think it would be good for the expect-ct spec to give reporting
servers a little non normative advice to be ready for cors and preflights.
Something complementary to the client mention now.

second, cors clearly makes some distinction between UA content and
content-content.. request headers for example. The notion being that the UA
can effectively make at least some decisions about what will botch things
up compared to what arbitrary JS might do. A whole request body formatted
by the UA, such as done by expect-ct reporting, must fall on this spectrum
somewhere (though I'm not certain where) in between. I agree with Emily
(and others in the thread cited) that not everything is subject to cors and
I'm not sure that "content controls the uri" is the sole determining factor.

But, as interesting as this discussion is, httpbis doesn't make cors
decisions. In that spirit the null origin stm the 'right way to use http'
if you can't figure out the real origin.. but text/plain (while being a
less true to the type'd nature of http) goes down the road of the "the UA
believes it has the right to declare this content safe enough to not
require cors" which also seems kinda reasonable overall if less pure http.




On Sat, Jun 10, 2017 at 10:55 AM, Martin Thomson <[e-mail]>
wrote:

> 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.)
>
>