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
OK, thanks — though in the case of the response from https://httpstat.us/204 it does seem to end up being a 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>
fetch("https://httpstat.us/200", { method: "HEAD" }).then(response => console.log(response.body))
09:54
<sideshowbarker>
fetch("https://httpstat.us/204").then(response => console.log(response.body))
09:55
<sideshowbarker>
https://fetch.spec.whatwg.org/#ref-for-null-body-status
thanks, looking now
09:55
<Luca Casonato>
That's a browser bug
09:55
<sideshowbarker>
OK
09:55
<Luca Casonato>

Deno does this correctly:

/m/s/P/g/denoland ❯❯❯ deno
Deno 1.18.2
exit using ctrl+d or close()
> fetch("https://httpstat.us/200", { method: "HEAD" }).then(response => console.log(response.body))

Promise { <pending> }
> null
> fetch("https://httpstat.us/204").then(response => console.log(response.body))

Promise { <pending> }
> null
10:19
<sideshowbarker>
That's a browser bug
OK, so based on simple testing just now, Safari, Firefox, and Chrome all seem to have this same 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:

test(function() {
  var response = new Response(null, {status: 204});
  assert_equals(response.body, null);
}, "Testing null Response body");
10:23
<Luca Casonato>

oh and this:

var nullBodyStatus = [204, 205, 304];
nullBodyStatus.forEach(function(status) {
  test(function() {
    assert_throws_js(TypeError,
      function() { new Response("body", {"status" : status }); },
      "Expect TypeError exception ");
  },"Throws TypeError when building a response with body and a body status of " + status);
});

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)
Oh I’d take one then, if that’s okay. “karwa” on GitHub.
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 blocking=render? It seems to me that it's allowed to have any value
I think you are right this is not correct. It is constrained to be a space-separated sequence of tokens but I made the wrong assumption that "supported tokens" helped with conformance.
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