| 12:34 | <JakeA> | Domenic: It seems a little surprising that moduleMap keys on URL and not URL + credentials. Or am I thinking about this wrongly? |
| 12:36 | <JakeA> | Domenic: Eg, if I'm deliberately trying to fetch a module with credentials, I may end up getting a non-credentialed version because some unrelated script imported it earlier without credentials |
| 12:48 | <annevk> | JakeA: it doesn't seem overly problematic |
| 12:49 | <annevk> | JakeA: and it's unclear whether the added complexity of the alternative is worth it |
| 12:50 | <JakeA> | annevk: Well, it just caught me out when I was creating a demo of script modules, but maybe it won't happen in the real world. |
| 12:51 | <annevk> | JakeA: did you want both separately? |
| 12:52 | <JakeA> | annevk: Yeah, but I was creating a demo where one script didn't have credentials and the next one did, so it isn't a real world example |
| 12:53 | <JakeA> | Surprised me though |
| 12:53 | <annevk> | JakeA: we also do this for SharedWorker, even across non-module/module boundaries |
| 12:54 | <annevk> | JakeA: it's a little surprising, but I'm not sure it's worth making the key more complicated |
| 12:55 | <JakeA> | annevk: I guess I expected it to work like the <img> cache |
| 12:55 | <JakeA> | In terms of using creds as part of the key anyway |
| 13:09 | <wanderview> | annevk: does a VARY header effect the moduleMap? |
| 13:11 | <annevk> | wanderview: nope |
| 13:14 | <wanderview> | I guess module map is not long lived? |
| 13:20 | <annevk> | wanderview: indeed, lifetime of the thing it's attached to |
| 14:37 | <tobie> | foolip: considering being a total jerk and manually overriding the webrtc url in Specref. :D |
| 15:08 | <jugglinmike> | annevk: I think I finally understand response filtering in Fetch, but it took me a while. It also threw a couple implementors for a loop, so I'm trying to see if we can make it any more clear |
| 15:08 | <jugglinmike> | but I recognize that it's actually a kind of complicated behavior, so I don't know if I'll really be able to improve on what we have already |
| 15:09 | <annevk> | jugglinmike: if you can that'd be great |
| 15:09 | <wanderview> | jugglinmike: annevk: did you guys come to a conclusion about the desired behavior? |
| 15:10 | <jugglinmike> | ah, no, wanderview--I didn't raise this with annevk |
| 15:10 | <annevk> | I gotta go and I haven't seen an issue... |
| 15:10 | <jugglinmike> | annevk: this is the test that wanderview, Mek, and I all agreed was "correct" on Friday https://github.com/w3c/web-platform-tests/compare/master...bocoup:sw-resp-tainting |
| 15:10 | <annevk> | I might be able to reply later today, but no guarantees |
| 15:10 | <jugglinmike> | ohh, okay |
| 15:11 | <annevk> | jugglinmike: oh right, I did look at that, and it looked reasonable, but a description of what I'm looking at would've helped |
| 15:11 | <wanderview> | annevk: I think the issue is that the spec actually might say the opposite of what we all thought was correct |
| 15:11 | <jugglinmike> | I haven't been able to write a coherent issue because I'm not so confident that anything is wrong here... Just a little confusing |
| 15:12 | <jugglinmike> | Yeah, wanderview's point was that a "basic filtered" response shouldn't be considered a "filtered response" at all |
| 15:12 | <wanderview> | or rather, that was surprising to me |
| 15:13 | <wanderview> | I would expect step 14 of main fetch to increase the tainting level if the request tainting is greater than the response tainting |
| 15:13 | <wanderview> | anyway, we should probably put this all in an issue |
| 15:14 | <annevk> | Hmm, yeah, does a synthetic response have any filter applied to it? |
| 15:14 | <annevk> | Anyway, issue would be good I guess |
| 15:14 | <jugglinmike> | Ahh, wanderview that's the ticket. There may be a problem where the outer fetch needs *more* filtering |
| 15:14 | <jugglinmike> | Okay, that's the insight I needed to write something coherent |
| 15:14 | <jugglinmike> | I'll get on that now |
| 15:15 | <wanderview> | jugglinmike: thats essentially the way I wrote it in gecko... https://dxr.mozilla.org/mozilla-central/source/dom/fetch/InternalRequest.h#363 |
| 15:16 | <wanderview> | and in the synthesized case it gets used here: https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerEvents.cpp#232 |
| 15:22 | <wanderview> | jugglinmike: thanks for working through this |
| 15:23 | <jugglinmike> | My pleasure (as unlikely as that may sound) |
| 18:26 | <aklein> | Domenic: can't remember if you were part of this conversation...are <script type=module>s supposed to work in XHTML? |
| 18:27 | <Domenic> | aklein: yeah, just like <script> |
| 19:50 | <Krinkle> | igrigorik: JakeA: annevk: FYI, I've filed an issue for the question from the other day- https://github.com/w3c/preload/issues/92 |
| 20:12 | <aklein> | Domenic: I worry that Object.prototype.toString is too performance-sensitive for a usecounter |
| 20:12 | <aklein> | Domenic: I know Angular hammers it pretty hard |
| 20:12 | <Domenic> | aklein: yeah, that's fair |
| 20:13 | <aklein> | but I definitely share the intuition that passing around the builtin prototype objects should be rare |
| 20:13 | <aklein> | how would one even get a handle on one? |
| 20:13 | <aklein> | I mean, by accident |
| 20:13 | <aklein> | do you know more about the [LenientThis] thing bz was talking about? |
| 22:37 | <jyasskin> | Have Service Workers run into trouble yet where a browser changes its Accept header, and all cached responses with "Vary: accept" get invalidated? |