You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior per Section 4.6 of the Fetch API
"Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored."
Actual behavior: Returns status code of 102 and empty response rather than waiting for the final 200 status code from the server.
The use case? Making a request to a server we don't control that responds
with a 102 status before sending the actual response. They do this because
the response may take longer than the usual socket timeouts.
Incidentally, this is why 1xx status codes exist in the first place.
I don't know about browsers. In general they support 100s, but I'll look it
up for sure with regard to the Fetch API. I'd be surprised if they have
completely different network connection logic for Fetch though.
Looks like you're using the http/https modules, which are broken with regard to the RFCs. I made a PR for the core Node project. We'll see how that pans out.
Issue: nodejs/node#9282
PR: nodejs/node#18033
I believe since node-fetch is listening to events from the http/https modules and the 'received' event only ever fires once, there is not much node-fetch can do for now except track the upstream bug and then make sure if committed that it doesn't break anything.
Activity
bitinn commentedon Dec 11, 2017
Hmm, the last time I checked this step wasn't there. Are browsers following this guideline?
Also, what sort of use cases are you using it for?
miles-po commentedon Dec 11, 2017
miles-po commentedon Dec 11, 2017
miles-po commentedon Jan 8, 2018
Looks like you're using the http/https modules, which are broken with regard to the RFCs. I made a PR for the core Node project. We'll see how that pans out.
Issue: nodejs/node#9282
PR: nodejs/node#18033
[-]"100 Continue" not following the spec[/-][+]"102 Processing" not following the spec[/+]TimothyGu commentedon Jan 8, 2018
@miles-po Thanks for filing the Node.js PR. Seems like a clean fix.
In the mean time, is there anything we on the node-fetch side can do to work around that bug?
miles-po commentedon Jan 8, 2018
I believe since node-fetch is listening to events from the http/https modules and the 'received' event only ever fires once, there is not much node-fetch can do for now except track the upstream bug and then make sure if committed that it doesn't break anything.
TimothyGu commentedon Feb 3, 2018
Okay, well not much we can do here then. Closing.