- From: Emily Stark <estark@google.com>
- Date: Sat, 10 Jun 2017 09:29:05 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, httpbis <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@annevk.nl>
- Message-ID: <CAPP_2SaK=1JO8Oz=k=LuSLBVqGQ2ZUZ1JYufF_N7YJaNhk=iuA@mail.gmail.com>
On Sat, Jun 10, 2017 at 1:55 AM, Martin Thomson <martin.thomson@gmail.com> 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 <estark@google.com> 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. > What's missing is the origin that triggered the request: in Fetch language, the request's client's origin, which populates the `Origin` header. Hence the suggestion for a preflight with a null Origin header and Access-Control-Allow-Origin: *. Which would be possible, and I think safe, but a bit hacky. Probably not more hacky than any of the other solutions under discussion, though. :) Having the request's client's origin available at connection setup time would require quite some gymnastics/re-design of the Chrome network stack, which late-binds sockets and does not know which request(s) a particular socket will be used for at connect time. > > 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.) > That's a good question, I have to think about that a bit.
Received on Saturday, 10 June 2017 16:29:59 UTC