Closed
Bug 1303025
Opened 7 years ago
Closed 6 years ago
Incorrect TypeError: Response body is given with a null body status.
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
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.
Assignee | ||
Comment 1•7 years ago
|
||
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
Comment 2•7 years ago
|
||
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)
Comment 4•7 years ago
|
||
Except the constructor itself has a nullable operator on the BodyInit type.
Flags: needinfo?(xidorn+moz)
Comment 5•7 years ago
|
||
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.
Updated•7 years ago
|
Blocks: ServiceWorkers-compat
Updated•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Keywords: dev-doc-needed
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
Comment hidden (mozreview-request) |
Assignee | ||
Comment 10•6 years ago
|
||
If there is no test checking this, I'll add a wpt later.
Assignee | ||
Comment 11•6 years ago
|
||
Looks like there is no such test at the moment...
Comment hidden (mozreview-request) |
Comment 13•6 years ago
|
||
mozreview-review |
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+
Comment 14•6 years ago
|
||
Pushed by xquan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/62f5c4a36823 Accept null for body param in constructor of Response. r=bkelly
Comment 15•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/62f5c4a36823
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•6 years ago
|
Assignee: nobody → xidorn+moz
Comment 16•6 years ago
|
||
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)
Keywords: dev-doc-needed → dev-doc-complete
Updated•5 years ago
|
status-firefox51:
affected → ---
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•