| 01:25 | <Domenic> | annevk: found this old related issue https://github.com/whatwg/html/issues/2579 |
| 10:55 | <MikeSmith> | annevk: where does the fetch spec normatively state the requirement that CORS requests can only have the http/https protocol scheme? |
| 11:12 | <annevk> | MikeSmith: in main fetch it might be somewhat implicitly stated |
| 11:13 | <annevk> | yoav: I’d be interested in learning more about the issues with squashing |
| 11:13 | <annevk> | jyasskin: ^^ |
| 11:17 | <MikeSmith> | annevk: yeah thinking about it more I realize that the protocol can‘ |
| 11:17 | <MikeSmith> | oofs |
| 11:17 | <MikeSmith> | *can’t work unless the response can include HTTP headers |
| 11:30 | <annevk> | MikeSmith: well, Fetch does have this abstraction where all responses have headers and such |
| 11:30 | <annevk> | MikeSmith: so assuming there's some suitable mapping, it's all good |
| 11:30 | <annevk> | MikeSmith: but Fetch also safelists schemes, so it's not all good |
| 11:52 | <MikeSmith> | annevk: I see. But there’s no way for a non-HTTP(S) server to add an Access-Control-Allow-Origin response header to a response, right? So regardless of the abstraction the spec, and non-HTTP(S) server can’t use the CORS protocol (to get browsers to relax the same-origin policy), right? |
| 11:59 | <annevk> | MikeSmith: is this theoretical or practical? |
| 12:08 | <MikeSmith> | annevk: practical; part of the context is, until today the MDN article on XHR contained a statement saying that ftp URLs could be used with the XHR API |
| 12:09 | <MikeSmith> | I removed that. But it occured to me that it would be helpful to have a clear explanation of why ftp requests can’t be made cross-orgin |
| 12:11 | <annevk> | MikeSmith: I think that's technically possible though |
| 12:11 | <annevk> | MikeSmith: if you get an ftp response sniffed as an HTML document that could then execute script to fetch something from the same server |
| 12:11 | <annevk> | MikeSmith: no CORS needed |
| 12:12 | <annevk> | (now some of these things might have gotten restricted over the years, I'm not exactly sure where we are at with FTP deprecation) |
| 12:12 | <annevk> | Domenic: that BarProp thing turns out to be a gigantic nerd-snipe |
| 12:18 | <MikeSmith> | annevk: I see. But nowadays CORB would anyway block an ftp response sniffed as an HTML document, right? So in practice it seems the gist of is that a cross-origin ftp request is just not gonna work in modern browsers ー though I guess maybe it could still work in some older browsers |
| 12:19 | <yoav> | annevk: For smaller PRs, I don't think squashing is a major concern, but once features become larger, loss of history once they get merged can be a problem. I know jyasskin was worried about that when it comes to SXG and Fetch integration |
| 12:23 | <annevk> | MikeSmith: I don't see why CORB would be at play here |
| 12:24 | <annevk> | yoav: there's something to that concern, I suspect |
| 12:25 | <annevk> | yoav: in such cases we've used pointers to the incubation repo in the past |
| 12:49 | <yoav> | annevk: Sure, but if all incubation happens on someone's Fetch repo GH fork, that's a bit weird |
| 12:55 | <yoav> | Is there a way for incubation to happen elsewhere without monkeypatching? I was thinking we could land hooks into the various related algorithms before we have consensus, and then be able to keep the logic in a separate doc, while not putting any processing into the WHATWG spec that don't have 2 vendor agreement |
| 13:04 | <annevk> | That doesn't sound acceptable to me |
| 14:56 | <yoav> | annevk: what part of it doesn't sound acceptable? Adding the hooks? |
| 14:58 | <annevk> | yoav: yeah, that's not materially different to a change to the standard |
| 16:01 | <jyasskin> | yoav/annevk: I'm missing some context here, but guessing: I was worried about maintaining SXG's fetch integration as a PR because it's just difficult to maintain long-lived topic branches, both because of merges and because I want review for changes to the fetch integration. |
| 16:01 | <jyasskin> | Losing the history after the merge wasn't my primary concern, and actually, that history's more likely to get lost from a monkeypatch merge than a long-lived PR merge. |
| 16:17 | <jyasskin> | annevk: Unrelated, our loading team is looking at implementing Bundles, but I haven't yet 1) finished what I think will be the final format or 2) written down how it integrates with Fetch and Service Workers. Clearly we won't *ship* before those are done, but how sad is it going to make Mozilla if we *implement* early? |
| 16:20 | <annevk> | jyasskin: ship is what folks care about afaik |
| 16:20 | <jyasskin> | annevk: Thanks. |
| 16:47 | <annevk> | Unicode might move to GitHub? Or only CLDR? |
| 17:07 | <jyasskin> | yoav/annevk: Oh! I've found the email: https://groups.google.com/a/chromium.org/d/msg/blink-dev/rspPrQHfFkI/B5vWGNhvCQAJ. I think the question of whether not-yet-merged features should live in PRs or in monkeypatches in a separate specification document, is orthogonal to the main question in that thread, which seems to be about when to ship at all. |
| 17:14 | <jyasskin> | annevk: Ignoring the political question of when to ship, I think I'm making the right tradeoff in https://wicg.github.io/webpackage/loading.html to let us review changes as we refine the design. |
| 20:19 | <annevk> | Domenic: I don't think we can remove global object reuse |
| 20:19 | <Domenic> | annevk: I was hoping minimize the number of cases it shows up, e.g., maybe for iframes |
| 20:19 | <annevk> | Domenic: for window.open("/common/blank.html") I'm pretty sure the document changes and the global stays the same |
| 20:19 | <annevk> | Domenic: I see |
| 20:20 | <Domenic> | I guess it's debatable whether minimizing in the way I propose makes things more or less complex |