freenode :: #whatwg

11 Aug 2017
01:11miketaylrMikeSmith: cool, good to know
07:16annevkIt's rather ridiculous that DreamHost hasn't fixed it given they have integration with Let's Encrypt for quite a while now
07:27a-jaannevk: "it" being?
07:31a-jacan't believe DreamHost still strands virtual hosting on Apache 2.2
07:52MikeSmithI 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 its just one person who is interested/able to handle that, then they become the bottleneck instead of Dreamhost support and borkedness being
07:52MikeSmiththe problem
07:52botiethe problem is a Bikeshed change
08:01a-jaMikeSmith, fwiw, Apache's working on a mod_md (as in Managed Domain)...haven't really delved into it too much yet
08:01a-jamight cut down on the sysadmin
08:03MikeSmithif we were to move to modern hosting I think one change that would come with it is moving to nginx
08:03MikeSmithIMHO it doesnt make sense to do anything new in Apache unless you really have to for some reason
08:04a-jahaven't seen anything about a built-in acme client for nginx yet
08:11MikeSmithdunno what acme is
08:11MikeSmithLets Encrypt?
08:11MikeSmithit has built-in support for easy automated nginx config
08:11MikeSmithLets Encrypt does
08:12MikeSmithcant say Ive ever used it though because I find it easy enough myself to just do that --standalone thing that doesnt touch server config files
08:13MikeSmithor --config-only or whatever the actual option is that controls that
11:29JakeA suggests that Firefox 55 supports async generators, but that doesn't seem to be the case
11:30TimothyGuJakeA: I think it's only about async generator *methods*
11:30TimothyGuas in ({ async* f() {} })
11:38JakeAahh ok
12:34annevkSimonSapin: I'm thinking of looking into data URLs since bz asked me to
12:34SimonSapinannevk: cool
12:34annevkSimonSapin: does look about right for tests?
12:35annevkSimonSapin: or is there some other angle a potential harness would need to concern itself with?
12:36SimonSapinannevk: is .text() Unicode?
12:36annevkSimonSapin: UTF-8 decode
12:36SimonSapinnot using charset from content-type?
12:37SimonSapinItd be good to be able to test that
12:37annevkSimonSapin: no, I guess maybe that rules it out yeah
12:37annevkBack to our trusted friend <iframe>
12:37annevkSimonSapin: anything else?
12:39SimonSapinhmm, ideally theres be an expected Unicode string for text/*, and and expected byte string for everything else
12:39SimonSapinbut I dont know how doable that is
12:40annevkSimonSapin: maybe byte string for everything is good enough since actual decoding of bytes can be tested separately
12:41annevkSimonSapin: that is, we&#39;re concerned that data URLs get turned into proper responses; how does responses get decoded is up to someone else
12:42JakeAannevk: Is it weird that the cloned request&#39;s signal will despatch onabort before the original&#39;s?
12:42annevkJakeA: it surprises me a bit
12:42SimonSapinannevk: I think we still want to test the extraction of an encoding label from the &quot;charset&quot; param
12:42annevkJakeA: I&#39;d have assumed the original would end up notifying the clone
12:43JakeAannevk: it does, but the &quot;run algorithms&quot; bit happens before despatching the event
12:44annevkSimonSapin: that is fair, but maybe that should be a separate set of tests
12:44JakeAannevk: I guess we could swap those around in the DOM spec. Set flag, despatch event, run algorithms
12:44JakeAnot sure if that would have a negative impact yet
12:45SimonSapinannevk: one test case I had was data:text/plain%3Bcharset=utf8,%F0%9F%92%A9
12:45annevkJakeA: ah
12:45annevkJakeA: I think generally you&#39;d want the event when everything else is done
12:46annevkJakeA: I guess it depends on what we end up using those algorithms for
12:46JakeAannevk: In the clone operation I could queue a microtask to despatch the event
12:46annevkJakeA: or maybe we should have a separate queue for forwarding events
12:46JakeAmicrotask seems hacky though
12:47annevkJakeA: yeah, you&#39;d get weird timing that way
12:47JakeAseparate queue would work
12:47annevkJakeA: worth asking some other folks if it would actually be bothersome
12:48annevkSimonSapin: good times
12:48annevkSimonSapin: I read through your old doc for inspiration already
12:51annevkSimonSapin: though I do think that charset extraction ought to be identical to that of Content-Type so I&#39;m still inclined to consider that separately and just make sure that matches each other
12:53SimonSapinisnt there a form with &quot;parameters&quot; like charset but no MIME type?
12:56annevkSimonSapin: I haven&#39;t seen that, but it&#39;d still need to become a Content-Type value first and then some other code would extract from that
12:56JakeAannevk: 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:15foolipannevk: looks like isn&#39;t auto-deploying, is there something that needs poking?
13:17annevkfoolip: I suspect we need to update the server public key similar to how I did for
13:17annevkfoolip: although here it&#39;s located in .travis.yml
13:17annevkfoolip: yeah, looking at Travis results that&#39;s it
13:17foolipannevk: oh right, that stuff. do you know how to fix it?
13:18annevkfoolip: sure I can do it
13:20annevkfoolip: done
13:23foolipok, so now works. I have a cached redirect in one browser, but assume it&#39;ll soon go away. thanks annevk !
16:55annevkSimonSapin: you were right btw, data:;charset=shift_jis,%C2%B1 is a thing
16:56annevkSimonSapin: I guess that means you can&#39;t really use a generic MIME type parser
20:14SimonSapinyeah :/
21:00DomenicI am excited for fixing data: URLs
12 Aug 2017
No messages
Last message: 9 days and 23 hours ago