| 00:07 | <Mek> | JonasNZ: from reading the spec it seems to me like Firefox might be correct. I.e. the Content-Type header is extrcated from the body in the Request constructor (or when calling fetch), if it isn't set already; and it isn't unset anywhere later... |
| 00:09 | <Mek> | (i.e. step 36 in https://fetch.spec.whatwg.org/#dom-request is what adds the header; and after that point the rest of the fetch algorithm as no way to distinguish a Content-Type header that might have been explicitly set by javascript from one that was extrcated from the body) |
| 00:49 | <JonasNZ> | In that case, I might suggest that the spec is wrong. I'll try and find the HTTP RFC, but I believe that the content type header for multipart/form-data is not valid for GET requests |
| 02:24 | <Jessidhia> | "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." |
| 02:24 | <Jessidhia> | so... it's UB |
| 02:24 | <Jessidhia> | ( https://tools.ietf.org/html/rfc7231#section-4.3.1 ) |
| 02:30 | <domfarolino> | Jessidhia: Ah it looks like JonasNZ had "quit" and "rejoined" in between you sending that, so not sure if he saw it |
| 02:49 | <Jessidhia> | we need later 7 TCP for this not for DCC 😆 |
| 03:24 | <MikeSmith> | Domenic: TabAtkins: FYI about the Can I Use limitation for mdn-prefixed IDs, I raised https://github.com/Fyrd/caniuse/issues/5187 |
| 03:26 | <MikeSmith> | and also raised https://github.com/tabatkins/bikeshed/issues/1553, for the resulting limitation in Bikeshed behavior |
| 03:26 | <Domenic> | Awesome |
| 03:26 | <Domenic> | As an aside, I wonder what's up with https://caniuse.com/#feat=mdn-api_abstractrange; does Edge 76 really support something Chrome doesn't? |
| 03:27 | <Domenic> | Also https://developer.mozilla.org/en-US/docs/Web/API/AbstractRange#Browser_compatibility is empty, interesting |
| 03:27 | <MikeSmith> | I think older non-Blink/Chromium Edge supported AbstractRange |
| 03:27 | <Domenic> | Yeah but not 76 I would assume |
| 03:28 | <MikeSmith> | yeah |
| 03:28 | <MikeSmith> | so that’s probably a bug in the browser-compat-data for AbstractRange |
| 03:29 | <Domenic> | Makes sense |
| 03:29 | <Domenic> | It does make me wonder if "multi-implementer experience" has been met anyway though |
| 03:29 | <Domenic> | Like in some cases W3C has counted Emacs as an implemnetation; it'd surprise me if they decided not to count old-Edge as one. |
| 03:31 | <MikeSmith> | well as far as what W3C is counting for actual web-platform features, in the HTML and DOM cases at least, I am not counting old-Edge |
| 03:32 | <Domenic> | Well, I guess that is a good change :) |
| 03:33 | <MikeSmith> | yeah well I can’t speak to what they might be counting or other specs, as far as Director decisions go |
| 03:34 | <Domenic> | I dunno maybe process 2020 will happen and everything will stay at CR forever without that criteria |
| 03:35 | <MikeSmith> | well I think the Evergreen thing is actually going to happen |
| 03:35 | <MikeSmith> | at least I have been led to believe so |
| 03:36 | <MikeSmith> | and for the WebDriver spec, the WG has also been told to believe so |
| 03:36 | <MikeSmith> | and same for the ServiceWorker spec |
| 03:36 | <Domenic> | Yeah it'd be nice |
| 03:38 | <MikeSmith> | about the problem with the compat table at https://developer.mozilla.org/en-US/docs/Web/API/AbstractRange#Browser_compatibility, it seems like that must just be a bug, but I don’t know where in their pipeline the cause might be nor where I should raise an issue for it.. |
| 03:40 | <MikeSmith> | and about Can I Use showing that Edge 76 has AbstractRange support, I think there’s probably a general/meta issue with BCD right now in that it hasn’t added general thing to account for the fact the underlying engine changed |
| 03:41 | <MikeSmith> | the edge data in https://github.com/mdn/browser-compat-data/blob/master/api/AbstractRange.json just has "version_added": "18" |
| 03:42 | <MikeSmith> | so I guess the way that Can I Use and anybody else downstream consumes that is to just consider any shipping version of Edge after 18 to have that same support |
| 03:43 | <Domenic> | Ah that makes sense |
| 03:44 | <MikeSmith> | yeah |
| 03:44 | <MikeSmith> | BCD has a version_removed field https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#version_removed |
| 03:46 | <MikeSmith> | ...but of course for that to have effect, it would need to be manually added to the BCD edge data in dozens of JSON files |
| 03:47 | <MikeSmith> | I think the easier solution is for everybody to just ignore Edge 76 and beyond, as far as feature data goes |
| 03:49 | <Domenic> | Yeah. I wonder if it'd make sense to treat it as a separate browser, and maybe fix things up on the frontend. |
| 04:44 | <MikeSmith> | Domenic: by the way, in other news, I recently updated https://www.w3.org/html/ |
| 04:45 | <MikeSmith> | part of the context is https://github.com/validator/validator/issues/890 |
| 04:46 | <MikeSmith> | in particular https://github.com/validator/validator/issues/890#issuecomment-555819316 |
| 04:47 | <MikeSmith> | ...which was an example of confusion due to https://www.w3.org/html/ pointing people to https://www.w3.org/TR/html52/ |
| 04:47 | <MikeSmith> | so lemme know if you have any refinements to suggest for text on https://www.w3.org/html/ |
| 04:49 | <MikeSmith> | as far as https://www.w3.org/TR/html52/ (and https://www.w3.org/TR/html51/, and https://www.w3.org/TR/html50/, and corresponding dated URLs like https://www.w3.org/TR/2017/REC-html52-20171214/)... |
| 04:50 | <Domenic> | Ah cool. I didn't know /html existed (just /TR/html) |
| 04:50 | <MikeSmith> | ... based on what I’ve been told, I think updating those needs to wait until the W3C Rec transition for HTML |
| 04:50 | <Domenic> | That all makes sense |
| 04:51 | <MikeSmith> | yeah, the https://www.w3.org/TR/html52/ URL is just a symlink to https://www.w3.org/TR/2017/REC-html52-20171214/ |
| 04:52 | <Domenic> | Hmm https://www.w3.org/TR/html53/ should be updatable now though I think? |
| 04:52 | <Domenic> | And dom41 |
| 04:52 | <Domenic> | since they are not recs |
| 04:53 | <Domenic> | I guess there are still a number of specs in https://www.w3.org/2019/04/WHATWG-W3C-MOU.html that need updating |
| 05:04 | <JonasNZ> | @Jessidhia: today hasn't been a good day for staying consistently in front of a computer - so sorry for the late response to your comment from earlier. You're right from the HTTP perspective. The content type itself though has expected behavior - althought I'm certainly not sure how to think about the interactionss between RFC1341 and the HTTP spec. |
| 05:05 | <JonasNZ> | Looking at this: https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html - "The body must then contain one or more 'body parts'" |
| 05:06 | <JonasNZ> | Gluing that together (admittedly whilst to defend my theory) it would seem that a GET request has no body, and thus cannot contain any parts, and thus can't form a valid multi-part message. |
| 05:08 | <JonasNZ> | At the same time HTTP/1.1 rfc says "HTTP is not a MIME-compliant protocol" |
| 05:16 | <annevk> | JonasNZ: a GET can contain whatever, but there’s an open issue on maybe dropping Content-* headers, look through issues with the topic: redirects label |
| 05:27 | <JonasNZ> | Thanks @annevk, very interesting reading. It seems like the conversation is converging on the behavior that Chrome seems to already exhibit. Either way, this gives me some things to subscribe to and enough understanding so I can work around the request parsing problems that led me here in the first place. |
| 05:32 | <JonasNZ> | Mek, Jessidhia, domfarolino, annevk - thank you all for the help, appreciate that you took the time to answer my questions. |
| 05:36 | <domfarolino> | annevk: just a heads up there is some discussion way above^ we had about lazy load + IO spec things in case you had any opinions |
| 05:58 | <annevk> | domfarolino: if HTML defines the primitive depending on that seems fine. |
| 06:00 | <domfarolino> | 👍 |
| 07:43 | <Jessidhia> | kinda like... you're stating the content-type T of the Maybe T, but instead of sending Just T you're sending Nothing instead 🤔 |
| 10:21 | <annevk> | Jessidhia: heh, I think the real problem here is that it's hard to come up with generic rules for redirects |
| 10:22 | <annevk> | Jessidhia: we could maybe strip some Content-* stuff if it becomes a GET request, but that wouldn't account for any custom metadata necessarily |
| 17:06 | <Domenic> | annevk: do you have time for some basic CORP questions? I could probably decipher the spec but I have a feeling asking you would be faster... |
| 17:07 | <Domenic> | s/CORP/COOP/ |
| 17:07 | <annevk> | Domenic: I can try |
| 17:08 | <Domenic> | So, first question: does COOP sever all opener relationships, or just all cross-origin ones? |
| 17:10 | <annevk> | Domenic: depends |
| 17:10 | <annevk> | Domenic: if COOP state matches same-origin works |
| 17:10 | <Domenic> | Hmm OK, so even same-origin things have to opt-in to having the opener relationship? |
| 17:11 | <annevk> | There’s also an open design issue where I propose changing some details |
| 17:11 | <annevk> | Domenic: yeah, otherwise it’d be too easy to escape |
| 17:11 | <Domenic> | Cool. Second question, how does COEP interact with COOP? I understand its interaction with CORP, but not COOP... |
| 17:12 | <annevk> | If you have COOP+COEP both are required for a match |
| 17:12 | <annevk> | So even higher stakes |
| 17:13 | <annevk> | Only when COOP is same-origin does it affect COOP |
| 17:13 | <Domenic> | I think I see |
| 17:14 | <annevk> | In the model COEP can change the COOP state to include it |
| 17:14 | <Domenic> | Next question, if a cross-origin popup wants to be treated as same-origin, similar to a cross-origin iframe that uses CORP, what does it do? |
| 17:15 | <annevk> | It cannot currently |
| 17:15 | <Domenic> | I guess more generally, COEP + CORP seem really simple for governing iframe interactions, so why can't we use that exact same model for popups? |
| 17:15 | <Domenic> | Interesting |
| 17:20 | <annevk> | Big difference is COOP |
| 17:20 | <annevk> | Would require a new kind of match |
| 17:20 | <annevk> | Prolly possible |
| 17:22 | <Domenic> | But like, why not just say, opener must put COEP: same-origin, and popup must either be same-origin or put CORP: cross-origin, and then that's good? What does COOP do for us? |
| 17:26 | <annevk> | COOP ensures takes care of popups the popup opens |
| 17:27 | <annevk> | And you cannot just give it COOP without some opt-in |
| 17:29 | <annevk> | FWIW, I do think you’re onto something that we should look into and possibly add |
| 18:15 | <annevk> | Domenic: thanks for finding the remaining instances of problematic child BCs, looking forward to writing a patch for them |
| 20:26 | <bradleymeck> | It seems the old MIME parser API PR from Node is now unblocked, I'll be rebasing it but we have an existing spec for the API using WebIDL at https://bmeck.github.io/node-proposal-mime-api/ . I'd be happy to figure out where we could get some cross review on it. |
| 20:31 | <Domenic> | bradleymeck: just glancing, it looks pretty nice, I'd just say s/mimeParams/params (or maybe parameters). |
| 20:31 | <Domenic> | Also I think you probably want to use maplike<> so that you can get keys/values/entries automatically. |
| 20:32 | <bradleymeck> | id be fine with either, and i can look at maplike |
| 20:32 | <Domenic> | The maplike change is mostly editorial, just makes the spec a little simpler. I think it does add keys/values/entries, but maybe iterable<> also adds those so I'm not sure. |
| 20:33 | <Domenic> | I think we're currently lacking strong use cases saying they would want this on the web, but e.g. if GoDaddy would use it on frontend, that could be compelling. |
| 20:34 | <Domenic> | As in, I think most people would like to add this, but nobody's employers can justify the time to implement it in their browsers. |
| 20:36 | <bradleymeck> | currently we are not looking at front end usage, but we would like it to at least appear to be ok if front end usage comes up after node |
| 20:37 | <Domenic> | makes sense |
| 20:37 | <Domenic> | I guess the spec doesn't have all the appropriate invariant-maintenance checks |
| 20:37 | <Domenic> | But you're aware of how to implement those since I know you've seen https://github.com/jsdom/whatwg-mimetype |
| 20:40 | <bradleymeck> | I'm not sure I understand that bit since it is delegating to the existing parser for those checks |
| 20:40 | <bradleymeck> | are there more checks that whatwg-mimetype is doing? |
| 20:40 | <Domenic> | On all the mutation methods |
| 20:41 | <bradleymeck> | https://bmeck.github.io/node-proposal-mime-api/#set-the-type throws type error on bad chars, perhaps this is an organization issue with my spec |
| 20:41 | <Domenic> | Oh yeah I found that now |
| 20:41 | <Domenic> | "set a parameter" is not referenced anywhere, is I think the only problem |
| 20:41 | <bradleymeck> | is there a better way to organize this? i modeled it after URL searchParams |
| 20:42 | <Domenic> | Same with "set the subtype" |
| 20:42 | <bradleymeck> | i'll double check those, good catch |
| 20:42 | <Domenic> | So yeah just cross-linking issues mostly |
| 20:43 | <bradleymeck> | any pref of params vs parameters in existing recommendations for wording? |
| 20:43 | <Domenic> | It's really hard to say; maybe others have opinions, but to me parameters is just enough on the long side that I'm unsure how to weigh that versus my natural preference against abbreviations. |
| 20:44 | <Domenic> | Also whatwg-mimetype will lowercase its arguments for the parameter-getting methods (has/get). I think that decision is debatable. |
| 20:45 | <Domenic> | Similarly I'm unsure whether the whitespace-stripping in your spec is a good idea. |
| 20:47 | <bradleymeck> | seems fine to remove, double checking browsers it seems they all lowercase the params when parsing anyway so perhaps it should always do that |
| 20:47 | <bradleymeck> | though idk, less magic might be better as other parts of things don't seem to change cases automatically |
| 20:48 | <bradleymeck> | will think |
| 20:48 | <Domenic> | I think you want to maintain the invariant that it's always lowercase |
| 20:48 | <Domenic> | (for param names) |
| 20:55 | <bradleymeck> | seems fine |
| 21:07 | <bradleymeck> | Domenic: is there an example of how to do validation on a maplike ? I see MIDI has a maplike but not seeing an example in the IDL doc or MIDI of validating key/value |
| 21:53 | <Domenic> | bradleymeck: wow, yeah, that doesn't seem to be a thing, so I guess maplike just isn't usable for this. Sorry for misleading. |
| 21:55 | <bradleymeck> | mostly updated but noticed the mime spec doesn't export some of its dfns |
| 21:57 | <Domenic> | You can bypass that with <a spec="mimesniff">...</a> |
| 21:58 | <Domenic> | Seems better not to export since this would eventually live in the MIME spec anyway. |
| 22:02 | <bradleymeck> | sounds fine to me |