| 00:05 | <TabAtkins> | MikeSmith: Nah, plinss did. |
| 00:06 | <TabAtkins> | Also, yeah, pkasting delivers some great one-liners. ^_^ |
| 09:37 | <tobie> | annevk: domain name's all set now. Thanks! We can add an index page if you want. Should I file a separate issue in meta for that? |
| 09:38 | <tobie> | annevk: …or just pile on the existing thread? |
| 09:41 | <annevk> | tobie: I'd make / redirect to whatwg.org for now |
| 09:42 | <annevk> | tobie: well, first redirect to HTTPS, then on HTTPS redirect / to whatwg.org |
| 10:05 | <annevk> | tobie: https://github.com/whatwg/misc-server/issues/5 has also some general server setup concerns |
| 10:06 | <tobie> | annevk: well, I can either do an amazon setup or let you handle the letsencrypt stuff. |
| 10:08 | <annevk> | tobie: can we get HSTS preload with an Amazon setup? |
| 10:08 | <annevk> | tobie: I don't really care where the cert comes from |
| 10:12 | <tobie> | annevk: answer to (1): I don't know and (2): I'll just do it with amz so I can move on to the getting HTML preview to work rather than spend tons of time on this stuff |
| 10:20 | <annevk> | tobie: sounds good, whenever there's more people with access someone else can take a look |
| 10:20 | <tobie> | annevk: sure |
| 10:24 | <annevk> | Wow, Amazon forum software uses tables |
| 10:24 | <annevk> | Seems https://forums.aws.amazon.com/thread.jspa?threadID=162252#jive-message-778226 has some information |
| 10:27 | <annevk> | mkwst: I strongly recommend leaving spec PRs open until tests are written and linked |
| 10:27 | <annevk> | mkwst: folks forget about them otherwise |
| 10:27 | <tobie> | mkohler: I |
| 10:27 | <tobie> | arg, sorry about that. |
| 10:28 | <annevk> | tobie: filed a misc-server issue to follow-up on this at some point |
| 10:28 | <mkwst> | annevk: I generally agree. But Martin sits right across from me, and he has to implement the thing in Chrome. I'm pretty sure we'll get tests in at that point. |
| 10:28 | <tobie> | annevk, mkwst: aren't you bumping into large merge conflicts all the time? |
| 10:29 | <mkwst> | tobie: Against HTML? Yeah. Against other specs? Not so much. |
| 10:29 | <tobie> | ok |
| 10:29 | <annevk> | mkwst: couple counter points to consider; 1) you serve as an example to others 2) your commits won't link to tests so they're harder to find in the future (also, see 1) 3) tests often uncover mistakes in the PR |
| 10:30 | <annevk> | tobie: almost never really; mostly against myself |
| 10:30 | <annevk> | tobie: though there is one extremely long running PR against Fetch that is losing out a lot |
| 10:31 | <mkwst> | annevk: That's all fair. |
| 10:32 | <tobie> | annevk: I find merge conflicts really scary to handle hence really wanting to avoid them |
| 10:33 | <annevk> | tobie: the main problem with IDL is that it was in such a bad shape |
| 10:33 | <tobie> | annevk: possibly |
| 10:33 | <annevk> | tobie: once a spec is in good shape it's unlikely you have to make changes all over |
| 10:33 | <tobie> | annevk: well, it still needs a lot of work |
| 10:33 | <annevk> | tobie: but it could depend on the spec I suppose |
| 10:34 | <tobie> | annevk: so there's that |
| 10:35 | <annevk> | tobie: but generally a merge conflict is easy to resolve versus resolving the questions that arise from writing tests |
| 10:36 | <tobie> | annevk: now that's a fair point. Again I'm biased here however, as WebIDL testing is all over the map |
| 10:36 | <tobie> | annevk: and idlharness is in a terrible shape |
| 10:36 | <annevk> | Yeah, I don't envy the position you're in |
| 10:46 | <tobie> | annevk: I just have to remember that some things might not apply right away because of WebIDL's tech debt |
| 10:48 | <annevk> | tobie: I'd be cautious though, since you or someone else will find themselves in two years going through the git log trying to figure something out |
| 10:49 | <tobie> | annevk: well, yeah, that's a good point too. |
| 10:49 | <tobie> | annevk: balancing these two things isn't easy |
| 10:49 | <annevk> | tobie: that is, any change you make now you're not absolutely sure on, you'll likely end up revisiting a bit |
| 10:50 | <annevk> | tobie: which can be fine to some extent, but... |
| 11:21 | <annevk> | tobie: I'm getting cert approval emails, forward? |
| 11:21 | <tobie> | annevk: oh... that's where they are. :D |
| 11:22 | <tobie> | annevk: yes please |
| 11:53 | <annevk> | Ms2ger: I cannot deop myself |
| 11:53 | <Ms2ger> | That's odd |
| 11:53 | <annevk> | I tried /msg chanserv deop #whatwg annevk |
| 11:53 | <annevk> | I'm not authorized... |
| 11:54 | <Ms2ger> | Try just /deop annevk |
| 11:54 | <annevk> | Whoa |
| 12:09 | <jochen__> | annevk: where would you expect it to be defined that a browser should have different cookie jars for connection on default ports vs non-default ports? |
| 12:13 | <jochen__> | also mkwst ^^^ |
| 12:26 | <mkwst> | Um. |
| 12:26 | <mkwst> | jochen__: Should browsers have different cookie jars for connectiosn on default ports vs non-default ports? :) |
| 12:27 | <jochen__> | yes! |
| 12:27 | <mkwst> | What would that mean? |
| 12:27 | <mkwst> | Like, double-keying all the cookies based on port? |
| 12:27 | <jochen__> | mkwst.com:31337 doesn't get cookies from mkwst.com |
| 12:27 | <jochen__> | no, just default port vs non-default |
| 12:28 | <annevk> | jochen__: I'd expect mkwst to fold that into the cookie RFC update |
| 12:28 | <mkwst> | So `example.com:80` frames `example.net` |
| 12:28 | <jochen__> | the actual goal I have is to introduce this differentiation for document.domain |
| 12:28 | <jochen__> | which is modelled after cookies |
| 12:28 | <mkwst> | And `example.com:1000` frames `example.net`. |
| 12:28 | <mkwst> | Does `example.net` have two different sets of cookies for those top-level contexts? |
| 12:28 | <mkwst> | Or do you only mean that `example.com:80` and `example.com:1000` have different cookies? |
| 12:29 | <annevk> | mkwst: the latter |
| 12:29 | <mkwst> | Ok. So, same jar, different labels. |
| 12:29 | <mkwst> | Yeah, we'd need to put that in the RFC. |
| 12:29 | <mkwst> | Fetch just delegates. |
| 12:29 | <annevk> | mkwst: basically add some kind of boolean to the cookie key (defaultPort) |
| 12:30 | <mkwst> | step 2.16.1.1 of https://fetch.spec.whatwg.org/#http-network-or-cache-fetch |
| 12:30 | <mkwst> | We're already passing in the current URL. Is that not enough? |
| 12:30 | <annevk> | mkwst: ooh I was talking about RFC changes, not Fetch changes |
| 12:31 | <annevk> | mkwst: the URL should be enough |
| 12:31 | <Ms2ger> | But `example.com:1000` and `example.com:1001` get the same cookies? |
| 12:31 | <mkwst> | Got it. Then we're on the same page. |
| 12:31 | <annevk> | Ms2ger: yeah |
| 12:31 | Ms2ger | puts his sense of logic back at the door |
| 12:31 | <mkwst> | So, yeah. That's how we'd want to do it if we wanted to do it. I'm not sure we want to do it? :) |
| 12:31 | <annevk> | Ms2ger: at least, that's the idea; once you go exotic you can have the weird legacy behavior |
| 12:32 | <mkwst> | I mean, yeah, sure, let's get cookies closer to origins than their wierd scoping today. |
| 12:32 | <mkwst> | It seems strange to include the port but not the subdomain. |
| 12:32 | <mkwst> | Maybe I'm missing the goal? |
| 12:32 | <annevk> | mkwst: I think jochen__ was motivated to further lock down document.domain |
| 12:33 | <annevk> | mkwst: I suggested that if we add this to document.domain, we should also add it to cookies |
| 12:33 | <annevk> | mkwst: since otherwise cookies would still have a broader scope |
| 12:33 | <jochen__> | https://www.chromestatus.com/metrics/feature/popularity#DocumentDomainSetWithNonDefaultPort |
| 12:33 | <annevk> | mkwst: we cannot restrict subdomains due to accounts.corp.example |
| 12:34 | <jochen__> | seems to be pretty rare |
| 12:34 | <annevk> | mkwst: but we can maybe restrict ports |
| 12:35 | <annevk> | mkwst: it seems somewhat worthwhile that a testing server on :8000 doesn't get account cookies |
| 12:35 | <mkwst> | jochen__: https://www.chromestatus.com/metrics/feature/timeline/popularity/2025 is a nice graph of folks' workdays. :) |
| 12:35 | <jochen__> | another option would be to have separate jars for <1024 and >= |
| 12:35 | <mkwst> | annevk, jochen__: Sure. I think it's totally worth trying to align these more closely with origins we know and love. |
| 12:35 | <jochen__> | :) |
| 12:36 | <mkwst> | I'm a little worried that changing cookie behavior will confuse developers because Chrome has terrible, terrible console integration for cookies. |
| 12:36 | <mkwst> | (And I'm not sure what we'd tell them anyway.) |
| 12:37 | <jochen__> | i'm not convinced we'd break a lot of things |
| 12:37 | <jochen__> | if you run your servers on non-default ports, you probably don't mix that with default |
| 12:38 | <mkwst> | I think `domain` is probably safe. The metric you landed measures all `set` operations, it doesn't measure how many of those actually resulted in successful cross-origin access when it would otherwise have been blocked. |
| 12:38 | <mkwst> | Since places like Facebook and DoubleClick set `document.domain` blindly, the actual impact is probably quite a bit lower than the number in that graph. |
| 12:38 | <mkwst> | That graph doesn't tell us much about cookies, though. |
| 12:41 | <mkwst> | *shrug* It's worth adding a flag and some metrics, I suppose. It'll be a little bit of work to hack something into the cookies backend, and we'll probably need to store another bit in the local db, but we could swing that if you wanted. |
| 14:00 | <Mek> | annevk: in https://github.com/w3c/FileAPI/issues/43#issuecomment-346922144 you're suggesting holding the mime type of a Blob in an internal slot and only serializing it when actually accessing the type attribute, but I'm not sure how I'm supposed to represent a MIME type other than as its serialized form? (in which case I'd just update the constructor logic to parse+reserialize, while still storing it as a string). Am I missing something in the mime specs? |
| 14:01 | <annevk> | Mek: https://github.com/whatwg/mimesniff/pull/36 |
| 14:01 | <annevk> | Mek: I still need review from Domenic and I need to write some more tests per feedback |
| 14:02 | <Mek> | ah okay, I'll wait with making any FileAPI changes until that is done then |
| 14:02 | <annevk> | Mek: that makes MIME types equal to URLs, if you're familiar with those |
| 14:02 | <annevk> | Mek: sounds good |
| 14:03 | <annevk> | (well, that plus the upcoming MIMEType object API) |
| 14:04 | <Mek> | that does look like it makes things a lot saner, yes |
| 14:07 | <Mek> | annevk: unrelated question, getting back to blob URLs, re https://github.com/w3c/web-platform-tests/pull/7848 (sorry, forgot about it and didn't notice you had actually commented on it), I'm not sure I like that behavior. I'm also not sure why the specs where changed at some point to do blob URL resolution at parsing time rather than fetch time, as it doesn't seem like browsers actually implement it that way |
| 14:07 | <Mek> | so not sure what the benefit would be of trying to change all implementations as opposed of just trying to allign the spec with implementations... |
| 14:08 | <Mek> | (although having said that, with the refactoring I'll have to do in chrome's implementation anyway it shouldn't be too hard to end up with what seems to be the currently specified behavior) |
| 14:10 | <Mek> | and to be fair I haven't fully explored exactly how every browser currently deals with blob URLs... working on that though |
| 14:14 | <annevk> | Mek: the main reason has been removing non-determinism |
| 14:15 | <annevk> | Mek: since we always parse synchronously (though, there may be exceptions and <img srcset> plays poorly, etc.) but never fetch synchronously |
| 14:15 | <annevk> | Mek: with fetching you never know when to revoke |
| 14:16 | <annevk> | Mek: in the sense of we all know blob: URLs are bad, but let's at least make them deterministically bad |
| 14:22 | <Mek> | hmm, good point... async fetching would definitely make things much harder to deal with. Didn't realize fetch didn't have some initial sync steps |
| 14:23 | <annevk> | Mek: we haven't really clarified that, but there's quite a bit of stuff that invokes fetch after going async |
| 14:24 | <Mek> | yeah, for one the fetch() API itself does |
| 14:27 | <Mek> | we do probably want to change a URL's origin to be actually stored explicitly rather than derived from other attributes btw. At least I'm not sure how else I'm going to make fetching blob URLs with unique origins work where at fetching time the mapping of URL to settings-object/origin might have already been revoked by revoking the URL |
| 14:28 | <annevk> | Mek: yes we do |
| 14:28 | <annevk> | Mek: that issue is blocked on the store refactoring |
| 14:29 | <annevk> | Mek: https://github.com/whatwg/url/issues/127 |
| 14:29 | <Mek> | yeah, working on that nowish... |
| 14:29 | <annevk> | also https://github.com/whatwg/url/issues/290 |
| 14:29 | <annevk> | hurray |
| 14:35 | <Mek> | I figured it'd be easier to bug you with anything I might run into while in the same timezone, which I happen to be these few weeks |
| 14:37 | <annevk> | Sure thing, you can always email too though or leave a question on IRC (if you stay connected) |
| 21:27 | <Domenic> | annevk: here is the JS mime type parser I used to find spec/test issues: https://github.com/jsdom/content-type-parser/pull/7 |