| 08:26 | <annevk> | JakeA: one thought about the naming, we already have MutationObserver |
| 08:27 | <annevk> | JakeA: I don't think having FetchObserver would be really problematic, but on the other hand MutationObserver is used more globally and there's been talk about having something similar for Fetch too, so maybe we should try to avoid that name |
| 08:28 | <JakeA> | annevk: I thought about that pattern too (also intersection/resize observer). It would be simpler for other platforms to implement than addeventlistener I guess |
| 08:29 | <JakeA> | annevk: I keep thinking about the "push" case, which might have side-effects |
| 08:30 | <JakeA> | annevk: given that push delivers request/response, we may only want to allow one listener |
| 08:30 | <annevk> | JakeA: fair point, though service workers doesn't follow that |
| 08:31 | <JakeA> | annevk: I guess the fetch event does too, and that allows multiple listeners. But a single observer may be in two threads |
| 08:31 | <JakeA> | Hah snap |
| 08:31 | <JakeA> | If you fetch from a page, the observer will be available to the page and the service worker |
| 08:31 | <annevk> | Perhaps we should restrict those features to the fetcher? |
| 08:32 | <annevk> | Seems hard to share them without cloning and cloning would be bad. |
| 08:32 | <annevk> | Perhaps you can opt-in to cloning and then they'd be shared. |
| 08:32 | <annevk> | The other thing I was wondering about is whether H2 push is associated with a request-response pair or with a connection |
| 08:33 | <annevk> | I think it's the former and then exposing them here makes a lot of sense |
| 08:33 | <annevk> | If it's the latter however it wouldn't |
| 09:03 | <JakeA> | annevk: push is associated with an existing stream, so it's linked to an initial request |
| 09:03 | <JakeA> | annevk: I also agree that push oddly is a better fit on the controller than the observer |
| 09:10 | <ondras> | https://tabatkins.github.io/specs/css-nesting/ |
| 09:10 | <ondras> | is this implemented anywhere? |
| 09:38 | <JakeA> | ondras: not that I'm aware of |
| 09:38 | <JakeA> | ondras: aside from http://cssnext.io/features/#nesting |
| 09:39 | <ondras> | JakeA: yeah, thanks, was interested in native implm |
| 09:40 | <ondras> | *impl |
| 09:44 | <JakeA> | annevk: there's some discussion of the push stuff already btw https://github.com/whatwg/fetch/issues/447#issuecomment-275178927 |
| 09:46 | <annevk> | JakeA: only exposing the request is interesting |
| 09:46 | <JakeA> | annevk: yeah, just writing something about that now |
| 14:14 | <tobie> | Domenic: bringing extension attributes to types is really exciting. Will review early next week |
| 14:16 | wanderview | wishes gmail used rel=noopener when opening multiple account windows. |
| 17:07 | <wanderview> | annevk: can an hsts upgrade affect a worker script load? |
| 17:07 | <annevk> | wanderview: so https://example.com/ with HSTS loads http://example.com/worker.js? |
| 17:08 | <annevk> | wanderview: that should work, but implementations may very still I think |
| 17:08 | <annevk> | wanderview: the same-origin check was done before the network fetch at some point |
| 17:08 | <wanderview> | annevk: I guess... or could it happen if an http://example.com tries to load the insecure worker script? can the csp only apply to the worker URL? |
| 17:09 | <annevk> | CSP or HSTS? |
| 17:09 | <wanderview> | HSTS I guess |
| 17:09 | <wanderview> | sorry, I don't know this stuff at all |
| 17:09 | <wanderview> | is HSTS scoped by URL or does it apply to an entire origin? |
| 17:09 | <annevk> | http://example.com is already insecure |
| 17:10 | <annevk> | HSTS applies to an domain, potentially including subdomains |
| 17:10 | <annevk> | s/an/a/ |
| 17:10 | <wanderview> | hmm |
| 17:15 | <annevk> | wanderview: happy to help, but I need a little more :-) |
| 17:15 | <wanderview> | annevk: I'm just trying to figure out if gecko allows redirects with a changing origin in any case... we have some non-standard stuff unfortunately |
| 17:16 | <wanderview> | looks like we do same origin checks before hsts upgrade could occur |
| 17:19 | <wanderview> | also, TIL today... Edge has nested workers! |
| 17:19 | <annevk> | wanderview: that sounds like old worker code indeed |
| 17:19 | <wanderview> | for some reason I thought gecko was the only code base with that complexity penalty |
| 17:19 | <annevk> | wanderview: I believe bz noticed that the other day too |
| 17:19 | <wanderview> | annevk: which part is old in this case? |
| 17:19 | <wanderview> | or sounds old |
| 17:20 | <annevk> | wanderview: doing a same-origin check in the constructor rather than as part of fetch |
| 17:20 | <wanderview> | annevk: we do it as part of the fetch... but earlier than hsts upgrade can occur |
| 17:20 | <wanderview> | I have to run... meeting someone for lunch |
| 17:20 | <wanderview> | thanks for the help |
| 17:21 | <annevk> | wanderview: oh wow, that would mean everything is affected, hmm |
| 17:23 | <annevk> | wanderview: actually Fetch does the same, I thought we didn't for same-origin requests, but it seems like we do it for all of them |
| 17:24 | <annevk> | wanderview: so what you're observing is likely just correct |
| 17:24 | <annevk> | wanderview: that is, it gets blocked in step 5 of https://fetch.spec.whatwg.org/#concept-main-fetchhttps://fetch.spec.whatwg.org/#concept-main-fetch due to being mixed content, HSTS upgrade only happens in step 9 |
| 17:37 | <Domenic> | annevk: I found an old link in https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0074.html that goes to http://html5.org/specs/dom-parsing.html#extensions-to-the-range-interface which redirects to domparsing.spec.whatwg.org which is broken. Should probably redirect to actual domparsing. |
| 17:38 | <annevk> | Domenic: I think it used to redirect |
| 17:38 | <annevk> | Domenic: you probably need to talk to Hixie, I suspect something broke |
| 17:38 | <Domenic> | I was kind of hoping we had the keys to html5.org |
| 17:39 | <Domenic> | And domparsing these days, ideally. |
| 17:39 | <annevk> | Domenic: so domparsing has a .htaccess that redirects |
| 17:39 | <annevk> | Domenic: it's just that domparsing doesn't have HTTPS for some reason |
| 17:40 | <annevk> | Domenic: I could change the html5.org redirect, but it seems the larger problem is domparsing not being up |
| 17:40 | <Domenic> | yes, i think it'd be good to fix both |
| 17:40 | <Domenic> | multi-redirects seem less than ideal |
| 17:41 | <annevk> | Domenic: commented in the issue |
| 23:50 | <tobie> | Domenic: trying to add your deploy script to w3c/sensors. Getting a request for the deploy_key passphrase on travis which times out. |
| 23:50 | <tobie> | Domenic: any idea? |
| 23:50 | <tobie> | Domenic: https://travis-ci.org/w3c/sensors/jobs/196039411 |
| 23:52 | <Domenic> | tobie: don't use a passphrase? |
| 23:52 | <tobie> | Domenic: It won's ask for it anyway? |
| 23:53 | <tobie> | Domenic: I could have checked instead of asked. sorry. :) |