Open Bug 1922110 Opened 5 months ago Updated 5 months ago

XHR/Fetch Requests return Network Error instead of API response when Response header Connection set to Close

Categories

(Core :: DOM: Networking, enhancement, P3)

Firefox 130
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: galaxytoeternity, Unassigned)

Details

(Whiteboard: [necko-triaged][necko-priority-next])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

As a developer, I wish to terminate larger file uploads when the server learns the data is no longer valid. I am using Node's readable.destroy() method to terminate the incoming stream (found here - https://nodejs.org/api/stream.html#readabledestroyerror).

To easily reproduce, I created a repo here - https://github.com/agadzinski93/test-cancel-upload

With it, you can upload a file (files are not actually uploaded anywhere, the streams are immediately destroyed) and see the network errors on the home page or in the Console/Network tab of the browser.

Actual results:

For larger uploads (at least a few MB), doing the above causes XHR/Fetch requests to hang even if I send a response from the API unless I set the HTTP Response header 'Connection' to 'close'. However, doing so causes XHR/Fetch requests to throw a network error.

Expected results:

The expectation is for the browser to return my APIs status code and response body if it exists. Only return a network error if none exists. This allows back-end developers to tell the client why the upload was terminated without having to upload the entire stream.

This works properly when using the API tool Postman. You can test this by sending a POST request on localhost:3000 (with my test project) with a file attached to form-data.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Networking
Product: Firefox → Core
Severity: -- → S3
Priority: -- → P3
Whiteboard: [necko-triaged][necko-priority-new]
Whiteboard: [necko-triaged][necko-priority-new] → [necko-triaged][necko-priority-next]

Update. I submitted this bug to the Chrome devs as well and was requested to create a video demonstrating the issue so I thought I'd upload it here as well to aid with your troubleshooting.

The quality is low since I lowered the bitrate to fit the 10MB file limit.

I'm using Chrome in the video, but the results are the same with Firefox.

In the video, I use my test project linked in the original post to test a small and large file. The browser and Postman both succeed with the small file. However, only Postman returns my API response with the larger file (400 error with a message of stream destroyed).

Hope this helps.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: