| 07:21 | <TimothyGu> | FWIW I wrote some tests for data: URLs for a node module a while a back: https://github.com/TooTallNate/node-data-uri-to-buffer/blob/master/test/test.js |
| 07:25 | <TimothyGu> | some things I noticed: Firefox defaults to US-ASCII (well windows-1252) by default for both data:,text and data:text/plain,text, but Chrome uses UTF-8 for data:text/plain,text and US-ASCII data:,text |
| 07:25 | <TimothyGu> | just another data point, hope it helps |
| 10:08 | <annevk> | TimothyGu: how did you test the defaulting? Did you have a control test that was delivered over HTTP instead? |
| 10:08 | <annevk> | TimothyGu: Chrome has a non-standard encoding sniffer, so I'd be very suspect |
| 10:31 | <TimothyGu> | annevk: I just navigated to the data: URL. I don't expect fetch/xhr to act any differently though |
| 10:32 | <TimothyGu> | I also used a UTF-8 string to test (data:text/plain,%E4%B8%AD%E6%96%87) |
| 10:32 | <TimothyGu> | i.e. "中文" |
| 10:34 | <annevk> | TimothyGu: I suspect that's just Chrome's behavior when you load a text/plain resource containing those bytes |
| 10:34 | <annevk> | TimothyGu: not really related to data URLs |
| 10:34 | <TimothyGu> | yeah that's what I think as well |
| 10:35 | <TimothyGu> | per RFC data:,text defaults to text/plain;charset=US-ASCII, but data:text/plain,text is just text/plain |
| 10:35 | <annevk> | This might be the only location we expose US-ASCII as a string |
| 10:36 | <annevk> | So sad |
| 10:36 | TimothyGu | :/ |
| 10:37 | <TimothyGu> | is there a PR or anything yet for whatwg/fetch? |
| 10:37 | <TimothyGu> | for data: that is |
| 10:42 | <TimothyGu> | annevk: IMO https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985 should also have a URL with text/plain but without charset |
| 10:43 | <annevk> | TimothyGu: there's nothing, I only worked on it a couple hours yesterday |
| 10:44 | <annevk> | TimothyGu: and yeah, need hundreds more tests |
| 10:45 | <TimothyGu> | ... |
| 10:46 | <annevk> | ? |
| 10:49 | <annevk> | TimothyGu: to be clear, that gist was mostly just a mockup for test format, the plan is to have that on WPT, probably with the tests in some kind of JSON resource again so they can be shared across impls |
| 10:49 | <TimothyGu> | just a bit surprised by "hundreds more tests" |
| 10:49 | <TimothyGu> | okay, that's wonderful |
| 10:49 | <annevk> | TimothyGu: oh, well, data URLs are complex |
| 10:49 | <annevk> | in a way |
| 11:49 | <Younder> | I'd say faulty URL parsing is the most common problem on the net |
| 11:50 | <Younder> | It does not render itself well to regexp parsing |
| 12:46 | <Domenic> | How does US-ASCII get exposed? |
| 12:48 | <Domenic> | (Fun story: in fifth grade I practiced how to pronounce ASCII, an unfamiliar phrase. Then I went to computer camp and the other kids made fun of me for saying "ay ess see eye eye" instead of "askee".) |
| 16:17 | <annevk> | TimothyGu: you should feel free to take over issues from Domenic I think |
| 16:17 | <annevk> | TimothyGu: especially if they haven't been touched in a while |
| 16:17 | <annevk> | TimothyGu: plenty on his plate |
| 16:18 | <annevk> | Domenic: the Content-Type header of the generated response has text/plain;charset=US-ASCII (consistently so across all impls) |
| 16:18 | <Domenic> | annevk: and .characterSet and aliases reflect the label, not the encosing name? |
| 16:19 | <annevk> | Domenic: .characterSet will be windows-1252 |
| 16:20 | <Domenic> | Oh ok... Next guess how the header is observable: new Response().headers? |
| 16:20 | <annevk> | Domenic: yup |
| 16:20 | <Domenic> | Hmm. That's a rather new API... But I guess XHR has the same problem |
| 16:21 | <annevk> | Domenic: you can do fetch(dataURL).then(res => console.log(res.headers.get("content-type")) |
| 16:21 | <annevk> | Domenic: yeah |
| 16:21 | <annevk> | I'm not even going to try change that really |
| 16:21 | <annevk> | It's the same across all impls and the RFC sorta requires it |
| 16:22 | <annevk> | It's silly, but whatever, it'll likely be way more effort to change that than it's worth, and the most we could change it too is windows-1252 I think, which isn't great |
| 16:24 | <annevk> | I'm leaning towards first splitting on "," which is somewhat contrary to the RFC, but is what everyone is doing |
| 16:24 | <annevk> | Nobody does data:x/x;x=",",x correctly |
| 16:37 | <MikeSmith> | so I’m wondering where it’s defined that using a ReadableStream object for uploads will result in a CORS preflight |
| 16:38 | <MikeSmith> | annevk: 👆 |
| 16:42 | <annevk> | MikeSmith: it's rather opaque |
| 16:42 | <annevk> | MikeSmith: the flag is set in step 38.2 of the Request constructor |
| 16:43 | <Domenic> | MikeSmith: annevk: I also don't understand that PR. I thought a bunch of other things caused CORS preflights, like unknown headers or methods. |
| 16:43 | <annevk> | MikeSmith: the reason we get there is because for a ReadableStream body's source will be null (it's the only object for which that is the case) |
| 16:44 | <annevk> | Domenic: that's different, those don't have a need for this flag as we can just check that in the fetch algorithm |
| 16:44 | <annevk> | Domenic: for these two cases the fetch algorithm has nothing to go on, that's why the flag is there |
| 16:44 | <Domenic> | Hmm OK. Well if we're planning on directing StackOverflow people there, maybe a note explaining that the use-CORS-preflight flag is just one factor in deciding whether to use a CORS preflight would be helpful |
| 16:45 | <MikeSmith> | annevk: ah OK yeah I knew that step is the only point in the Fetch spec itself wehre the use-CORS-preflight flag gets set, but didn’t know using a ReadableStream object for uploads would lead to that step |
| 16:46 | <annevk> | Domenic: good point, would you mind adding that MikeSmith? |
| 16:46 | <MikeSmith> | Domenic: I can expand on the note |
| 16:46 | <MikeSmith> | yeah |
| 16:46 | <MikeSmith> | I also updated the MDN CORS article for this point recently |
| 16:49 | <annevk> | I think yutakahirano did a good job with the streams stuff, but it would've been nice if we had more reviewers and more people invested in the various algorithms |
| 16:49 | <annevk> | JakeA's been reviewing a bit due to cancelation integration which has helped I think |
| 16:53 | <annevk> | I keep being surprised that you need something like Uint8Array to access data in an ArrayBuffer |
| 17:00 | <MikeSmith> | OK, pushed an update do that PR |
| 17:00 | <MikeSmith> | now reads: |
| 17:00 | <MikeSmith> | > The use-CORS-preflight flag being set is just one of several conditions that can result in a CORS-preflight request. The use-CORS-preflight flag will be set if either one or more event listeners are registered on an XMLHttpRequestUpload object, or else if a ReadableStream object is used for uploads. |
| 17:01 | MikeSmith | steps away now to get some sleep |