| 12:07 | <annevk> | JakeA: I still need to look into this more, but I just realized that if we put the valid opaque response URL on the request we don't need to have a side table in the network layer anymore, that's a lot cleaner |
| 12:08 | <annevk> | JakeA: and I guess we do want to merge the two efforts somehow, although I'm not sure if I want to sign up for fixing media element loading |
| 12:09 | <JakeA> | annevk: yeah, I agree that data could go onto the request, and a future 'fix' to media elements could use it |
| 12:10 | <annevk> | JakeA: did browsers ever implement your fixes? |
| 12:13 | <JakeA> | annevk: The big security issues are handled by preventing redirects that go to different places, but I don't think it's interoperable |
| 12:13 | <annevk> | Putting it on a request also makes it scoped to a single media element, which seems a lot cleaner. I guess there is an assumption that service workers would always do pass through for these though. |
| 12:14 | <annevk> | But maybe the Cache API deals poorly with 206 anyway? |
| 12:14 | <JakeA> | annevk: the request would only have its "valid opaque response URL" set if the response has to come from that location, so the service worker would need to do pass-through in that case |
| 12:15 | <JakeA> | If a media element only uses non-opaque responses then the service worker can get the data from wherever it wants |
| 12:15 | <annevk> | Yeah, I mean that's an implication of doing it that way and not having the network layer track these responses in some way... |
| 12:16 | <JakeA> | ahh ok |
| 12:16 | <annevk> | But that also relied on a media element doing the initiation so never mind |
| 15:01 | <annevk> | JakeA: since the HTML PR never went anywhere, do you know if bugs got filed against all browsers? |
| 15:02 | <JakeA> | annevk: I only filed bugs for the actual security issues I found. I didn't file bugs to converge behaviour. In some ways it's good I didn't, since my proposal in that PR wasn't solid enough. |
| 15:03 | <annevk> | JakeA: if you still have those somewhere I'd love the Fx bug |
| 15:04 | <annevk> | JakeA: also, is this something you are willing to spend more time on? Perhaps the HTML part only and I'll do the Fetch part as part of ORB? |
| 15:04 | <JakeA> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1441153 |
| 15:05 | <JakeA> | annevk: I'll put it on my TODO list, although there are more folks waiting on me to do the browser session & session history stuff first |
| 15:07 | <annevk> | JakeA: ah yeah, that's important too |
| 15:09 | <annevk> | JakeA: okay, maybe I'll make time for it, but this ORB thing is becoming quite the yak shave with embed/object/media elements |
| 15:36 | <annevk> | JakeA: reading https://bugs.chromium.org/p/chromium/issues/detail?id=532569 I also wonder if we need changes to CORS to allow for Range to be set and not cause a preflight |
| 15:37 | <annevk> | what a mess |
| 15:41 | <annevk> | Ah, https://github.com/whatwg/fetch/issues/145 mentions this at least |
| 16:53 | <JakeA> | I wonder if https://fetch.spec.whatwg.org/#privileged-no-cors-request-header-name helps there? |
| 17:02 | <annevk> | JakeA: yeah I think so, we just need to use that as a way to bypass the preflight |
| 17:02 | <annevk> | JakeA: but more annoyingly it'll need tests |
| 17:03 | <annevk> | Hopefully I'll have some time this week to look into all that |