09:42 | <sideshowbarker> | annevk: with the fetch API, if a response has no body — for example, for a 204 response — will response.body be null? context: https://github.com/mdn/content/issues/12862#issuecomment-1034609833 |
09:45 | <annevk> | sideshowbarker: yeah, it would make sense for it to be null in that case |
09:45 | <annevk> | (and the spec allows for it to return null) |
09:47 | <sideshowbarker> | sideshowbarker: yeah, it would make sense for it to be null in that case ReadableStream and not null. But maybe that’s due to them sending a 0-byte response? (if that’s actually possible) |
09:48 | <annevk> | sideshowbarker: that would be a browser bug per spec... |
09:49 | <annevk> | sideshowbarker: spec special cases a couple of response codes |
09:49 | <sideshowbarker> | ah |
09:49 | sideshowbarker | looks back at the spec |
09:53 | <sideshowbarker> | hmm I’m not finding anything about special-casing in the spec that would allow an empty response to ever be a ReadableStream rather than null |
09:54 | <Andreu Botella> | https://fetch.spec.whatwg.org/#ref-for-null-body-status |
09:54 | <sideshowbarker> | and even testing with a HEAD request, I still get a ReadableStream |
09:54 | <sideshowbarker> |
|
09:54 | <sideshowbarker> |
|
09:55 | <sideshowbarker> | https://fetch.spec.whatwg.org/#ref-for-null-body-status |
09:55 | <Luca Casonato> | That's a browser bug |
09:55 | <sideshowbarker> | OK |
09:55 | <Luca Casonato> | Deno does this correctly:
|
10:19 | <sideshowbarker> | That's a browser bug |
10:19 | <Luca Casonato> | :D |
10:20 | <sideshowbarker> | yeah, so I think I probably now need to do a follow-up to the MDN change I made, to indicate that while the spec says it should be null, browsers don’t conform |
10:21 | <annevk> | So if you do new Response().body it's null in Firefox, but maybe once networking gets involved it gets messed up |
10:21 | <Luca Casonato> | I thought there was a WPT for this (I remember fixing it in Deno). But that might actually have only covered the new Response(null, {status: 204}) case |
10:22 | <annevk> | I'm surprised this isn't tested as well, but I have not paid as close attention to all the streams stuff |
10:23 | <Luca Casonato> | This is the only related test I can find right now:
|
10:23 | <Luca Casonato> | oh and this:
|
10:24 | <Luca Casonato> | I can add some tests start of next week |
17:30 | <Karl> | If anyone here isn't part of the WHATWG GitHub org but has contributed please let me know (unless you don't care for an invite) |
18:06 | <mek> | How do reviews work on whatwg specs? Or I guess how do I find out who other than myself has write access to approve PRs to the new FS spec (since I presumably shouldn't approve my own changes, even if they are purely editorial)? |
18:12 | <annevk> | mek: sorry, I've been meaning to get to it, but huge backlog is huge; maybe Domenic can help out |
18:13 | <annevk> | mek: one thing I found kinda strange is that the for= attribute didn't contain the name of the term, but I didn't really take the time to explore |
18:15 | <annevk> | At a more meta-level, we don't really have a system and if it turns out to be prohibitive for your spec, we can remove the reviewer requirement; I'd recommend against doing that though, it's usually worth the wait |
18:15 | <mek> | I'm totally in favor of reviews, the fact that github gives no way to even figure out who can give reviews is mostly annoying... |
18:17 | <annevk> | mek: right, I think currently it's you and WHATWG admins, but we can add more folks, e.g., inexorabletash and asuth are reviewers for Storage |
19:54 | <zcorpan> | Domenic: did you consider document conformance rules when reviewing blocking=render ? It seems to me that it's allowed to have any value |
20:03 | <Domenic> | Domenic: did you consider document conformance rules when reviewing |
20:04 | <Domenic> | "A blocking attribute must have a value that is an unordered set of unique space-separated tokens. " -> "A blocking attribute must have a value that is an unordered set of unique space-separated tokens, each of which is a possible blocking token"? |
22:07 | <zcorpan> | Domenic: right. Yeah, the proposed text should do it I think |
22:08 | <zcorpan> | Domenic: I found another bug in the idl, will report an issue |