| 00:33 | <jyasskin> | Does anyone know where we handle the maximum length of a URL? |
| 00:37 | <Mek> | is there a maximum length for URLs in general? https://tools.ietf.org/html/rfc7230#section-3.1.1 seems to describe how servers should treat URLs that are too long, and mentions that clients and servers should support at least ~8K |
| 04:16 | <jyasskin> | Mek: I think it varies by browser, in practice, but I don't see even permission in Fetch for a browser to reject a too-long URL. |
| 04:17 | <Mek> | fetch just seems to leave that part up to the set of http specs? |
| 04:17 | <Mek> | but yeah, I have no idea what browsers actually do |
| 07:30 | <annevk> | Yeah, some bits of HTTP are being incorporated such as header parsing, so there is room for this. HTTP defining it for all clients is preferable though. |
| 07:38 | <annevk> | Domenic: I was hoping someone else would do an initial pass |
| 07:38 | <annevk> | Domenic: seems domfarolino might have done so from a quick glance |
| 07:40 | <domfarolino> | Yeah I briefly looked earlier when I saw the link. Happy to check it out in more detail though. |
| 07:42 | <annevk> | domfarolino: that’d be great |
| 13:47 | <annevk> | Domenic: https://gist.github.com/annevk/5c2df7a49db621a2c1cd4f3fb78210af |
| 13:48 | <annevk> | Domenic: I was thinking of posting that to the issue, for additional context, but happy to expand on things if it's unclear still |
| 13:49 | <Domenic> | annevk: I'd prefer making the top-level BC and auxiliary BC set explicit independent slots, instead of one big set |
| 13:51 | <Domenic> | I'm also a bit concerned about doing the worker changes separately leaving us with a hard-to-understand mismash, but wanting to chunk the work is also understandable... |
| 13:52 | <annevk> | Domenic: for the worker stuff the current declarative definition doesn't seem entirely problematic |
| 13:52 | <Domenic> | Yeah agreed, but having two different styles for very similar things seems like it'd be confusing. |
| 13:52 | <annevk> | Domenic: I'm not really sure what independent slots buys us here and it might make things more complicated for various traversal operations |
| 13:53 | <Domenic> | Independent slots make the model a lot clearer to me. You don't think there will be a use for getting the single top-level BC? |
| 13:53 | <annevk> | I'm afraid folks would use that kind of thing instead of finding the root of their tree, which is what they really need to be doing |
| 13:54 | <annevk> | (most of the time) |
| 13:54 | <annevk> | Because of the long conflation of top-level and auxiliary to mostly mean the same thing |
| 13:54 | <Domenic> | Hmm |
| 13:54 | <Domenic> | Well, I guess keep it in mind while writing the algorithms... I suspect it'll be clearer than a big bag that has hidden structure. |
| 13:55 | <annevk> | I guess if some state from top-level is important, it'd be better to store that directly on BCG |
| 13:55 | <annevk> | Though it's unclear what would happen if the top-level was closed |
| 13:55 | <annevk> | (which is another thing I wouldn't expect folks to deal well with) |
| 13:56 | <Domenic> | Right... wait, doens't the definition of top-level handle that? |
| 13:56 | <Domenic> | Oh, so right now I think all auxiliary BCs are also top-level BCs |
| 13:56 | <annevk> | right |
| 13:56 | <Domenic> | Let's not change that? |
| 13:57 | <Domenic> | E.g. there is a bunch of spec work like https://github.com/w3c/payment-request/pull/811 |
| 13:57 | <annevk> | Agreed, perhaps I'm stressing the difference I want to point out incorrectly |
| 13:57 | <Domenic> | Yeah, probably need new terms |
| 13:57 | <annevk> | I guess I could say there's at most one non-auxiliary browsing context |
| 13:58 | <Domenic> | "root browsing context"? "original browsing context"? |
| 13:58 | <annevk> | root would ideally be equal to top-level if we reuse DOM tree terms |
| 13:58 | <Domenic> | This section will benefit from examples that map more directly to tabbed browsers than we usually talk about in the spec |
| 13:59 | <Domenic> | Maybe I can work on some diagrams and ask you to write nice text around them :) |
| 13:59 | <annevk> | That sounds great |
| 13:59 | <Domenic> | I think there's an open clarification issue about diagrams |
| 14:00 | <annevk> | Maybe the distinction top-level/auxiliary doesn't even matter as much anymore with BCGs |
| 14:00 | <annevk> | Because any important state would be anchored there |
| 14:00 | <Domenic> | Well it's not a distinction |
| 14:00 | <annevk> | And any BC can be an opener BC |
| 14:00 | <annevk> | Domenic: sorry, the non-auxiliary/auxiliary distinction |
| 14:01 | <Domenic> | I think specs like https://github.com/w3c/payment-request/pull/811 or feature policy do care about top-level-ness |
| 14:01 | <Domenic> | Not sure who if anyone cares about auxiliaryness |
| 14:01 | <annevk> | Care about non-auxiliaryness or care about top-levelness? |
| 14:01 | <Domenic> | I can't think of anything besides the window.opener spec that cares about auxiliariness |
| 14:03 | <Domenic> | Although I guess maybe some of the security stuff gets inherited into auxiliary... but maybe that's better served by BC groups... |
| 14:03 | <annevk> | Yeah, we might be able to do away with that term |
| 14:03 | <Domenic> | It still seems roughly useful to be able to talk about popup windows in some way, but maybe it's more confusing than helpful, and it's better to just talk about top-level BCs that have an opener versus don't. |
| 14:04 | <annevk> | Have an opener is dangerous as you can set it to null, but it might still be too late |
| 14:05 | <annevk> | That's why BCGs also help |
| 14:05 | <annevk> | (Although not to locate popups, as the initial top-level might be closed.) |
| 14:05 | <Domenic> | I guess we'll probably also get to clean that up and have disowning actually set opener to null |
| 14:05 | <Domenic> | Right now I think we keep it around so that they stay in the same URSOBCs |
| 14:05 | <annevk> | We cannot, because the WindowProxy can be leaked at any point |
| 14:06 | <Domenic> | We can set the opener to null and keep them in the same BCG I think |
| 14:06 | <annevk> | So they'll have to stay in the same BCG and the same agent cluster |
| 14:06 | <annevk> | Ah yes |
| 14:06 | <Domenic> | Whereas right now we "disown the opener" but leave the pointer there |
| 14:06 | <Domenic> | Which is confusing |
| 14:06 | <annevk> | Yeah it's bad |
| 15:32 | smaug____ | wonders if anyone has ever considered to merge Referrer Policy into Fetch. |
| 16:07 | <annevk> | smaug____: I don’t think that has come up |
| 16:22 | <smaug____> | it just might, or might not, make fetch handling easier to read. |
| 20:08 | <innovati> | Not quite how to put it - but is it possible for a portion of an HTML page to define and use its own namespace? |
| 23:56 | <Domenic> | TabAtkins: does anything define how CSS background images or fonts get fetched? E.g. what referrer URL they send? |
| 23:57 | <Domenic> | I guess maybe https://w3c.github.io/webappsec-referrer-policy/#integration-with-css implies the answer is "no", but I can just point to that spec instead... |
| 23:57 | <TabAtkins> | There is none, yes. |