Closed Bug 1303025 Opened 4 years ago Closed 3 years ago

Incorrect TypeError: Response body is given with a null body status.

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: xidorn, Assigned: xidorn)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

Steps to reproduce:
1. Open Web Console
2. Enter "new Response(null, {status: 204})"

Expected result:
return a Response object

Actual result:
TypeError: Response body is given with a null body status.


This is an issue for Fetch, but I have no idea what component Fetch belongs to, so just put in ServiceWorker.
I guess the issue is at [1].

The spec says in [2]:
> If body is non-null, run these substeps:
but the code at [1] only checks whether the value is passed.


[1] https://dxr.mozilla.org/mozilla-central/rev/8a494adbc5cced90a4edf0c98cffde906bf7f3ae/dom/fetch/Response.cpp#194
[2] https://fetch.spec.whatwg.org/#dom-response
Xidorn, I believe null is being converted to "null" because BodyInit is not a nullable type and DOMString is one of its union types.  If you do this, then it works:

  var r = new Response(undefined, { status: 204 })

Does this make sense?
Flags: needinfo?(xidorn+moz)
And fetch just goes in Core/DOM
Component: DOM: Service Workers → DOM
Except the constructor itself has a nullable operator on the BodyInit type.
Flags: needinfo?(xidorn+moz)
Which we are missing in our webidl:

https://dxr.mozilla.org/mozilla-central/source/dom/webidl/Response.webidl#10

Seems we need `optional BodyInit? body` there.
Priority: -- → P3
I too have run into this issue. Please refer to the following specs for fetch. The body getter must return null or stream, so 'undefined' will never occur [1]. Also the status reference for response says that it must be null for 101, 204, 205, or 304 [2]. And finally body is allowed to be null, and "body is said to be done if body is null or body’s stream is closed or errored" [3], So creating a Response with a body of 'undefined' is actually not "done" as the spec describes

[1] https://fetch.spec.whatwg.org/#dom-body-body
[2] https://fetch.spec.whatwg.org/#concept-status
[3] https://fetch.spec.whatwg.org/#concept-body
noted that Chrome and Edge both allow null as the body when building a Response object
Please ignore my previous comment. This is not about what other browsers allow, but rather how Firefox has implemented the standard. Cheers
If there is no test checking this, I'll add a wpt later.
Looks like there is no such test at the moment...
Comment on attachment 8942406 [details]
Bug 1303025 - Accept null for body param in constructor of Response.

https://reviewboard.mozilla.org/r/212712/#review218884

Thanks!
Attachment #8942406 - Flags: review?(bkelly) → review+
Pushed by xquan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/62f5c4a36823
Accept null for body param in constructor of Response. r=bkelly
https://hg.mozilla.org/mozilla-central/rev/62f5c4a36823
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Assignee: nobody → xidorn+moz
I've documented this by:

* Updating the description and support info on the constructor page: https://developer.mozilla.org/en-US/docs/Web/API/Response/Response
* Adding a note to the Fx59 rel notes: https://developer.mozilla.org/en-US/Firefox/Releases/59#DOM

Let me know if this is OK, thanks!
Flags: needinfo?(xidorn+moz)
Looks good, thanks.
Flags: needinfo?(xidorn+moz)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.