| 01:11 | <miketaylr> | MikeSmith: cool, good to know |
| 07:16 | <annevk> | It's rather ridiculous that DreamHost hasn't fixed it given they have integration with Let's Encrypt for quite a while now |
| 07:27 | <a-ja> | annevk: "it" being? |
| 07:27 | <annevk> | a-ja: lists.whatwg.org |
| 07:31 | <a-ja> | can't believe DreamHost still strands virtual hosting on Apache 2.2 |
| 07:52 | <MikeSmith> | I think our problem with moving off Dreamhost remains that if we did it right it means moving to hosting on a VM with root access (at Digital Ocean or wherever) and that means one or more people would probably need to spend more time doing sysadmin tasks and if it’s just one person who is interested/able to handle that, then they become the bottleneck instead of Dreamhost support and borkedness being |
| 07:52 | <MikeSmith> | the problem |
| 07:52 | <botie> | the problem is a Bikeshed change |
| 08:01 | <a-ja> | MikeSmith, fwiw, Apache's working on a mod_md (as in Managed Domain)...haven't really delved into it too much yet |
| 08:01 | <a-ja> | might cut down on the sysadmin |
| 08:03 | <MikeSmith> | if we were to move to modern hosting I think one change that would come with it is moving to nginx |
| 08:03 | <MikeSmith> | IMHO it doesn’t make sense to do anything new in Apache unless you really have to for some reason |
| 08:04 | <a-ja> | haven't seen anything about a built-in acme client for nginx yet |
| 08:11 | <MikeSmith> | dunno what acme is |
| 08:11 | <MikeSmith> | Let’s Encrypt? |
| 08:11 | <a-ja> | yeah |
| 08:11 | <MikeSmith> | it has built-in support for easy automated nginx config |
| 08:11 | <MikeSmith> | Let’s Encrypt does |
| 08:12 | <MikeSmith> | can’t say I’ve ever used it though because I find it easy enough myself to just do that --standalone thing that doesn’t touch server config files |
| 08:13 | <MikeSmith> | or --config-only or whatever the actual option is that controls that |
| 11:29 | <JakeA> | https://developer.mozilla.org/en-US/Firefox/Releases/55 suggests that Firefox 55 supports async generators, but that doesn't seem to be the case |
| 11:30 | <TimothyGu> | JakeA: I think it's only about async generator *methods* |
| 11:30 | <TimothyGu> | as in ({ async* f() {} }) |
| 11:38 | <JakeA> | ahh ok |
| 12:34 | <annevk> | SimonSapin: I'm thinking of looking into data URLs since bz asked me to |
| 12:34 | <SimonSapin> | annevk: cool |
| 12:34 | <annevk> | SimonSapin: does https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 look about right for tests? |
| 12:35 | <annevk> | SimonSapin: or is there some other angle a potential harness would need to concern itself with? |
| 12:36 | <SimonSapin> | annevk: is .text() Unicode? |
| 12:36 | <annevk> | SimonSapin: UTF-8 decode |
| 12:36 | <SimonSapin> | not using charset from content-type? |
| 12:37 | <SimonSapin> | It’d be good to be able to test that |
| 12:37 | <annevk> | SimonSapin: no, I guess maybe that rules it out yeah |
| 12:37 | <annevk> | Back to our trusted friend <iframe> |
| 12:37 | <annevk> | SimonSapin: anything else? |
| 12:39 | <SimonSapin> | hmm, ideally there’s be an expected Unicode string for text/*, and and expected byte string for everything else |
| 12:39 | <SimonSapin> | but I don’t know how doable that is |
| 12:40 | <annevk> | SimonSapin: maybe byte string for everything is good enough since actual decoding of bytes can be tested separately |
| 12:41 | <annevk> | SimonSapin: that is, we're concerned that data URLs get turned into proper responses; how does responses get decoded is up to someone else |
| 12:42 | <JakeA> | annevk: Is it weird that the cloned request's signal will despatch onabort before the original's? |
| 12:42 | <annevk> | JakeA: it surprises me a bit |
| 12:42 | <SimonSapin> | annevk: I think we still want to test the extraction of an encoding label from the "charset" param |
| 12:42 | <SimonSapin> | ideally |
| 12:42 | <annevk> | JakeA: I'd have assumed the original would end up notifying the clone |
| 12:43 | <JakeA> | annevk: it does, but the "run algorithms" bit happens before despatching the event |
| 12:44 | <annevk> | SimonSapin: that is fair, but maybe that should be a separate set of tests |
| 12:44 | <JakeA> | annevk: I guess we could swap those around in the DOM spec. Set flag, despatch event, run algorithms |
| 12:44 | <JakeA> | not sure if that would have a negative impact yet |
| 12:45 | <SimonSapin> | annevk: one test case I had was data:text/plain%3Bcharset=utf8,%F0%9F%92%A9 |
| 12:45 | <annevk> | JakeA: ah |
| 12:45 | <annevk> | JakeA: I think generally you'd want the event when everything else is done |
| 12:46 | <annevk> | JakeA: I guess it depends on what we end up using those algorithms for |
| 12:46 | <JakeA> | annevk: In the clone operation I could queue a microtask to despatch the event |
| 12:46 | <annevk> | JakeA: or maybe we should have a separate queue for forwarding events |
| 12:46 | <JakeA> | microtask seems hacky though |
| 12:47 | <annevk> | JakeA: yeah, you'd get weird timing that way |
| 12:47 | <JakeA> | separate queue would work |
| 12:47 | <annevk> | JakeA: worth asking some other folks if it would actually be bothersome |
| 12:48 | <annevk> | SimonSapin: good times 😊 |
| 12:48 | <annevk> | SimonSapin: I read through your old doc for inspiration already |
| 12:51 | <annevk> | SimonSapin: though I do think that charset extraction ought to be identical to that of Content-Type so I'm still inclined to consider that separately and just make sure that matches each other |
| 12:53 | <SimonSapin> | isn’t there a form with "parameters" like charset but no MIME type? |
| 12:56 | <annevk> | SimonSapin: I haven't seen that, but it'd still need to become a Content-Type value first and then some other code would extract from that |
| 12:56 | <JakeA> | annevk: The more I think about it, allowing a signal to have a list of signals that should copy it makes sense. Especially as we might add an API for that in future |
| 13:15 | <foolip> | annevk: looks like https://github.com/whatwg/whatwg.org/pull/36 isn't auto-deploying, is there something that needs poking? |
| 13:17 | <annevk> | foolip: I suspect we need to update the server public key similar to how I did for resources.whatwg.org |
| 13:17 | <annevk> | foolip: although here it's located in .travis.yml |
| 13:17 | <annevk> | foolip: yeah, looking at Travis results that's it |
| 13:17 | <foolip> | annevk: oh right, that stuff. do you know how to fix it? |
| 13:18 | <annevk> | foolip: sure I can do it |
| 13:20 | <annevk> | foolip: done |
| 13:23 | <foolip> | ok, so https://whatwg.org/faq now works. I have a cached redirect in one browser, but assume it'll soon go away. thanks annevk ! |
| 16:55 | <annevk> | SimonSapin: you were right btw, data:;charset=shift_jis,%C2%B1 is a thing |
| 16:56 | <annevk> | SimonSapin: I guess that means you can't really use a generic MIME type parser |
| 16:56 | <annevk> | ugh |
| 20:14 | <SimonSapin> | yeah :/ |
| 21:00 | <Domenic> | I am excited for fixing data: URLs |