| 09:11 | <yoav> | annevk: hey! I've aligned TAO processing to what we previously talked about CORS does: https://github.com/w3c/resource-timing/pull/214 |
| 09:11 | <yoav> | now got a question on that PR saying that it'd be great to point at what CORS does https://github.com/w3c/resource-timing/pull/214#pullrequestreview-289023889 |
| 09:13 | <yoav> | but I'm having a hard time finding what to point at. Fetch seems to run the CORS check above redirects, and I'm not 100% sure how tainted origins fit into that |
| 09:13 | <annevk> | yoav: I'm not sure I understand the logic in the PR |
| 09:14 | <yoav> | (I'm painfully aware that the PR in question doesn't provide full Fetch integration, but didn't want to hold that observable difference between CORS and TAO until full integration happened) |
| 09:14 | <annevk> | yoav: when following redirects Fetch will change the requesting origin to an opaque origin when multiple origins are crossed |
| 09:14 | <annevk> | yoav: which means that only null can match it |
| 09:14 | <annevk> | yoav: but I don't see that in your text |
| 09:15 | <annevk> | (well, and * for non-credentialed requests) |
| 09:16 | <annevk> | yoav: ooh sorry, these days we set a tainted flag |
| 09:16 | <annevk> | yoav: see step 10 of https://fetch.spec.whatwg.org/#http-redirect-fetch for when it gets set |
| 09:17 | <yoav> | yeah, saw the flag set, but not sure where it's taken into account along with a CORS check |
| 09:17 | <annevk> | yoav: step 4 of https://fetch.spec.whatwg.org/#concept-cors-check |
| 09:18 | <annevk> | yoav: in particular the request's origin will serialize as null |
| 09:18 | <yoav> | oh, https://fetch.spec.whatwg.org/#serializing-a-request-origin |
| 09:18 | <yoav> | got it! |
| 09:28 | <yoav> | annevk: one more point, is the tainted flag setting influenced by any CORS checks? Didn't see any |
| 09:30 | <annevk> | yoav: what do you mean? |
| 09:30 | <yoav> | should the cross-origin redirects also opt-in to CORS? Or is it sufficient that the final response does? |
| 09:31 | <annevk> | yoav: redirects also need to carry CORS headers |
| 09:32 | <yoav> | can you point me to that part in the processing? saw CORS checks only in HTTP fetch and CORS-Preflight fetch |
| 09:32 | <annevk> | yoav: 4.4 of https://fetch.spec.whatwg.org/#http-fetch happens before the redirect is processed |
| 09:32 | <annevk> | yoav: and then if we hit another redirect, that'll go through 4.4 again |
| 09:33 | <yoav> | ok, cool |
| 09:33 | <annevk> | yoav: in particular note that before step 5 of HTTP fetch we haven't really done much with the status code (other than perhaps HTTP authentication) |
| 09:33 | <annevk> | (oh, and ranges and 304, they happen earlier) |
| 11:03 | <annevk> | Domenic: will you make the cancel() method throw if someone passes in a signal to a stream? |
| 11:03 | <Domenic> | annevk: I don't think so, it'd just be another mechanism for canceling the stream. |
| 11:04 | <annevk> | Domenic: JakeA's comment made me wonder if we should add abort() to fetch()'s theoretical FetchObserver, but it seemed to me whoever vends the signal might not like that being an option |
| 11:05 | <Domenic> | It depends on the programming model, yeah, I'm not sure. |
| 11:05 | <annevk> | Domenic: though I suppose that if you invoke fetch() yourself you can always not pass the signal anyway |
| 11:05 | <annevk> | Domenic: but if someone handed you the result of fetch() or a created stream it might be nice if you get to do things with it, but not decide to cancel it |
| 11:07 | <Domenic> | I think for streams at least the single-consumer model means you should get all the powers once you have the stream |
| 11:07 | <Domenic> | Like, reading is destructive, so allowing reads but not cancels isn't very useful. |
| 11:07 | <annevk> | Domenic: I had one other thought on import maps, rather than require import URLs, have a way to make all fetches go through it; that way you can use common names like jquery for images and CSS too |
| 11:08 | <Domenic> | annevk: yeah, I mean we could do that especially for URL-like specifiers. But bare specifiers, I'm not sure, <a href="jquery"> or <script src="jquery"> already have a meaning. |
| 11:09 | <annevk> | hmm yeah, I guess there's all the API mismatch |
| 11:09 | <annevk> | I have a feeling this is the second time I've had this realization |
| 11:10 | <JakeA> | Domenic: in the fetch abort discussions, folks seemed to want to keep observation and abort separate |
| 11:10 | <Domenic> | JakeA: doesn't make sense for streams at least |
| 11:11 | <Domenic> | JakeA: since read() is just as destructive as cancel() |
| 11:17 | <JakeA> | Agreed |
| 11:22 | <Domenic> | Anyone have a reference to the "async decisions only" policy that I've heard mentioned? Is it in some popular charters or something? |
| 11:29 | <annevk> | Domenic: what's the context? end-user UI? |
| 11:29 | <Domenic> | annevk: contrasting with TC39 |
| 11:30 | <annevk> | Domenic: ooh WG decision making |
| 11:31 | <annevk> | Domenic: so I looked at https://whatwg.org/working-mode#changes and we don't mention that even though it's a somewhat critical part of our Working Mode |
| 11:31 | <Domenic> | We have a thing in FAQ about no F2F meetings |
| 11:32 | <annevk> | We might have to adjust that a bit too since there certainly are meetings affecting stuff we develop |
| 11:34 | <annevk> | I think the main thing is that all decisions are subject to appeal when done within a reasonable amount of time |
| 11:35 | <annevk> | And generally we don't make substantive changes without allowing at least a week for discussion |
| 11:35 | <annevk> | Maybe s/substantive/major/ |
| 12:05 | <annevk> | Domenic: filed https://github.com/whatwg/sg/issues/98 and also created a PR for the FAQ |
| 12:07 | <annevk> | Ah you saw, doh |
| 12:08 | <Domenic> | Nice, I ask a small question and annevk improves all our docs, my work here is done ^_^ |
| 12:08 | <Domenic> | Ramen time... |
| 12:20 | <annevk> | Jealous |
| 13:46 | <domfarolino> | oof just had some ramen myself |
| 13:55 | <MikeSmith> | I already miss the ramen in Fukuoka |
| 14:43 | <annevk> | TabAtkins: heya, when do you think we can make progress on https://github.com/tabatkins/bikeshed/issues/964? |
| 14:44 | <annevk> | TabAtkins: it spans about 4 repos so there's some fun dependency problems, but there's also the issue of not having a patch at all for Bikeshed and me really wishing you would write it |
| 15:02 | <TabAtkins> | ^_^ I can go ahead and do it this week. |
| 15:02 | <TabAtkins> | Taking some recovery days from losing weekends to travel, but I'll be working on Wednesday |
| 15:03 | <annevk> | \o. |
| 15:03 | <annevk> | / |