| 10:00 | <andreubotella> | annevk: w.r.t https://github.com/whatwg/html/pull/6287#issuecomment-762646151, see https://github.com/whatwg/html/issues/6247#issuecomment-753997698 |
| 10:00 | <andreubotella> | I might have done a poor job explaining, but although "string/File-sourced entries" include programmatic inputs (such as some FACE inputs), "FormData-sourced entries" are all programmatic |
| 10:02 | <andreubotella> | so my initial idea was to keep things as they were in the spec, other than normalizing FormData-sourced entries for urlencoded and text/plain since Firefox and Chrome already do that |
| 10:06 | <annevk> | andreubotella: I might not have been clear enough either, I think I meant to not normalize them at all |
| 10:07 | <annevk> | andreubotella: it's kinda moot without implementer input though and I suspect it might be hard to get a quick take from someone given all the intricacies |
| 10:07 | <andreubotella> | annevk: true |
| 10:09 | <annevk> | andreubotella: I think you had a summary comment somewhere about the current state of things in implementations, perhaps that can be updated with the proposed state and then we get feedback on that? |
| 10:09 | <annevk> | andreubotella: pretty sure I can reach someone from Chrome; I think for Mozilla it doesn't matter much as long as we end up with interop |
| 10:11 | <andreubotella> | annevk: turns out that for Firefox, doing it some other way than the current state of https://github.com/whatwg/html/pull/6287 would need fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1651887 first |
| 10:12 | <andreubotella> | but sure, I'll write that up |
| 10:13 | <annevk> | andreubotella: that bug is a good indicator that folks don't want their FormData "magically" changed |
| 10:14 | <annevk> | (though more likely is that it's anecdata that reinforces my biases 🙂) |
| 10:17 | <andreubotella> | annevk: Firefox and Chrome agree on normalizing FormData-sourced entries on urlencoded and text/plain, though |
| 10:18 | <andreubotella> | and Safari only doesn't because it can only create a payload from FormData-sourced entries with Request/Response.body |
| 10:20 | <andreubotella> | so if we don't want to normalize FormData entries on Request.body, the shortest path to interoperability would probably going with Chrome for multipart/form-data |
| 10:23 | <annevk> | andreubotella: I'm sorry, but I no longer know what that means |
| 10:23 | <annevk> | Interop matters, but if everyone has to do a little more and we end up with something a lot simpler that's valuable too, esp. long term |
| 10:55 | <annevk> | andreubotella: what does (names and filenames N/A) mean? |
| 10:56 | <andreubotella> | annevk: Firefox turns newlines into spaces in the MIME headers in multipart/form-data |
| 10:56 | <andreubotella> | with https://github.com/whatwg/html/pull/6282, that's no longer conforming to the spec |
| 10:56 | <annevk> | andreubotella: that might be worth noting |
| 10:57 | <andreubotella> | right |
| 10:57 | <annevk> | andreubotella: I hadn't really considered that names would become headers; can you even reliably parse that format if those contain newlines? |
| 10:58 | <andreubotella> | https://github.com/whatwg/html/pull/6282 makes them percent-escaped |
| 10:58 | <annevk> | I see |
| 10:58 | <annevk> | That should work |
| 10:59 | <andreubotella> | That's why I waited to file both PRs together in the same Firefox bug |
| 11:01 | <annevk> | andreubotella: I still like the idea of normalizing for String/File and not normalizing for FormData |
| 11:03 | <andreubotella> | annevk: I'd prefer normalizing everything for urlencoded and text/plain and going the Chrome way on multipart/form-data |
| 11:03 | <andreubotella> | but let's wait to hear from the implementers |
| 11:04 | <annevk> | andreubotella: why is that your preference? |
| 11:06 | <andreubotella> | annevk: I'm not sure; the other options are definitely simpler |
| 11:07 | <andreubotella> | I don't care too much which way we end up going for multipart/form-data |
| 11:51 | <andreubotella> | annevk: I was thinking that for urlencoded and text/plain, it might not be simpler to not normalize for FormData, spec-wise and for implementations like Chrome |
| 11:52 | <andreubotella> | I'll try to put my words in order and write a post about it |
| 13:52 | <annevk> | JakeA: so how do you trick a media element into making multiple range requests? |
| 14:03 | <JakeA> | annevk: give it back less than it wants. If it asks for 0-, give it 0-100 or whatever |
| 14:03 | <JakeA> | it'll make another request for the rest |
| 14:03 | <JakeA> | either that, or seek the media |
| 15:47 | <annevk> | JakeA: so both Chrome and Firefox seem to give up for cross-origin audio, even without redirects, not sure what to make of this yet (perhaps DevTools is broken) |
| 15:48 | <JakeA> | annevk: give up, as in don't make a second range request? |
| 15:48 | <annevk> | JakeA: yeah, and Firefox doesn't even show the first request |
| 15:48 | <annevk> | JakeA: get a single progress event in Chrome, two in Fx |
| 15:50 | <JakeA> | annevk: https://github.com/jakearchibald/range-request-test might be useful, as this logs the requests the server receives |
| 15:51 | <annevk> | JakeA: yeah, looking at WPT stashes now |
| 15:52 | <JakeA> | annevk: https://github.com/web-platform-tests/wpt/blob/master/fetch/range/general.window.js here's what I did for the range stuff in wpt |
| 15:52 | <annevk> | JakeA: yeah I'm using some of that 🙂 |
| 15:52 | <annevk> | JakeA: if I get somewhere you might even get a review request |
| 15:52 | <annevk> | but prolly not today at this rate |
| 15:53 | <JakeA> | 😀 happy to |
| 16:20 | <annevk> | JakeA: it's really weird, if I append a uuid it doesn't happen anymore; maybe it hits some cache somewhere |
| 16:55 | <JakeA> | annevk: hmm, it's possible. Does no-store produce the same effect? |
| 17:01 | <annevk> | JakeA: does not seem to matter; I've also "disable cache" enabled |
| 17:01 | <JakeA> | huh, that is odd |
| 17:01 | <annevk> | JakeA: anyway, not investigating that too much, looking more at redirects and such now |
| 17:02 | <annevk> | JakeA: it seems that Chrome might stop at the first redirect, Firefox at the first cross-to-same-origin redirect, Safari keeps trucking, I guess I need to test cross-to-cross origin |
| 17:03 | <JakeA> | annevk: I seem to remember that Chrome would 'remember' the redirect, and consult the redirected-to URL for subsequent parts, whereas Firefox would go back to the original URL |
| 17:03 | <JakeA> | Or the other way around |
| 17:06 | <annevk> | JakeA: I can reproduce Firefox continuing with the original URL, but Chrome stops after it gets the 206 response from the redirect |
| 17:07 | <annevk> | Which is admittedly weird and maybe a sign I'm doing something wrong as it would make more sense for Chrome to just abort upon seeing a redirect after the initial fetch |
| 17:08 | <annevk> | JakeA: ah, if the initial request redirected I can reproduce that behavior in Chrome |
| 17:08 | <annevk> | JakeA: but not if the second request redirects |
| 17:09 | annevk | basically branches of a request counter to try to make browsers do stupid stuff |
| 17:09 | <JakeA> | ohhhh! I think that behaviour is new to me |
| 17:10 | <annevk> | JakeA: maybe it still follows redirects in the hope that the final URL is identical and it will continue in that case? That does kinda match what mkwst described |
| 17:12 | <JakeA> | annevk: As in redirects to another origin and back again? That would surprise me, but everything about this stuff surprises me |
| 17:41 | <annevk> | JakeA: as in, if the first request ends up at /x and the second request thus goes to /x but then is redirected to various places including https://y/test but ends up at /x, it's okay (not verified though, will likely do so tomorrow) |
| 21:10 | <smaug____> | Are some directories in wpt magical, so that files in them aren't run? |
| 21:11 | <smaug____> | Or do all the .html files with <script src="/resources/testharness.js"></script> or <script src="/resources/testharnessreport.js"></script> or something get run as a test |
| 21:25 | <Domenic> | The latter |