freenode :: #whatwg

12 Aug 2017
07:21TimothyGuFWIW I wrote some tests for data: URLs for a node module a while a back:
07:25TimothyGusome 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:25TimothyGujust another data point, hope it helps
10:08annevkTimothyGu: how did you test the defaulting? Did you have a control test that was delivered over HTTP instead?
10:08annevkTimothyGu: Chrome has a non-standard encoding sniffer, so I'd be very suspect
10:31TimothyGuannevk: I just navigated to the data: URL. I don't expect fetch/xhr to act any differently though
10:32TimothyGuI also used a UTF-8 string to test (data:text/plain,%E4%B8%AD%E6%96%87)
10:32TimothyGui.e. ""
10:34annevkTimothyGu: I suspect that's just Chrome's behavior when you load a text/plain resource containing those bytes
10:34annevkTimothyGu: not really related to data URLs
10:34TimothyGuyeah that's what I think as well
10:35TimothyGuper RFC data:,text defaults to text/plain;charset=US-ASCII, but data:text/plain,text is just text/plain
10:35annevkThis might be the only location we expose US-ASCII as a string
10:36annevkSo sad
10:36* TimothyGu :/
10:37TimothyGuis there a PR or anything yet for whatwg/fetch?
10:37TimothyGufor data: that is
10:42TimothyGuannevk: IMO should also have a URL with text/plain but without charset
10:43annevkTimothyGu: there's nothing, I only worked on it a couple hours yesterday
10:44annevkTimothyGu: and yeah, need hundreds more tests
10:49annevkTimothyGu: 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:49TimothyGujust a bit surprised by "hundreds more tests"
10:49TimothyGuokay, that's wonderful
10:49annevkTimothyGu: oh, well, data URLs are complex
10:49annevkin a way
11:49YounderI'd say faulty URL parsing is the most common problem on the net
11:50YounderIt does not render itself well to regexp parsing
12:46DomenicHow does US-ASCII get exposed?
12:48Domenic(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:17annevkTimothyGu: you should feel free to take over issues from Domenic I think
16:17annevkTimothyGu: especially if they haven't been touched in a while
16:17annevkTimothyGu: plenty on his plate
16:18annevkDomenic: the Content-Type header of the generated response has text/plain;charset=US-ASCII (consistently so across all impls)
16:18Domenicannevk: and .characterSet and aliases reflect the label, not the encosing name?
16:19annevkDomenic: .characterSet will be windows-1252
16:20DomenicOh ok... Next guess how the header is observable: new Response().headers?
16:20annevkDomenic: yup
16:20DomenicHmm. That's a rather new API... But I guess XHR has the same problem
16:21annevkDomenic: you can do fetch(dataURL).then(res => console.log(res.headers.get("content-type"))
16:21annevkDomenic: yeah
16:21annevkI'm not even going to try change that really
16:21annevkIt's the same across all impls and the RFC sorta requires it
16:22annevkIt'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:24annevkI'm leaning towards first splitting on "," which is somewhat contrary to the RFC, but is what everyone is doing
16:24annevkNobody does data:x/x;x=",",x correctly
16:37MikeSmithso Im wondering where its defined that using a ReadableStream object for uploads will result in a CORS preflight
16:42annevkMikeSmith: it's rather opaque
16:42annevkMikeSmith: the flag is set in step 38.2 of the Request constructor
16:43DomenicMikeSmith: annevk: I also don't understand that PR. I thought a bunch of other things caused CORS preflights, like unknown headers or methods.
16:43annevkMikeSmith: 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:44annevkDomenic: that's different, those don't have a need for this flag as we can just check that in the fetch algorithm
16:44annevkDomenic: for these two cases the fetch algorithm has nothing to go on, that's why the flag is there
16:44DomenicHmm 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:45MikeSmithannevk: 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 didnt know using a ReadableStream object for uploads would lead to that step
16:46annevkDomenic: good point, would you mind adding that MikeSmith?
16:46MikeSmithDomenic: I can expand on the note
16:46MikeSmithI also updated the MDN CORS article for this point recently
16:49annevkI 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:49annevkJakeA's been reviewing a bit due to cancelation integration which has helped I think
16:53annevkI keep being surprised that you need something like Uint8Array to access data in an ArrayBuffer
17:00MikeSmithOK, pushed an update do that PR
17:00MikeSmithnow reads:
17:00MikeSmith> 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
13 Aug 2017
No messages
Last message: 9 days and 20 hours ago