Open Bug 1808868 Opened 2 years ago Updated 2 years ago

backpressure support for fetch API

Categories

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

Firefox 108
defect

Tracking

()

UNCONFIRMED

People

(Reporter: nighca, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

As mentioned in fetch spec:

The user agent may be asked to suspend the ongoing fetch. The user agent may either accept or ignore the suspension request. The suspended fetch can be resumed. The user agent should ignore the suspension request if the ongoing fetch is updating the response in the HTTP cache for the request.

The user agent does not update the entry in the HTTP cache for a request if request’s cache mode is "no-store" or a Cache-Control: no-store header appears in the response.

By slow down or stop reading from the stream (response.body) returned by fetch, we can suspend the ongoing fetch, which means stop receiving in TCP layer.

Currently, chrome supports that when the response's header includes Cache-Control: no-store, while it is still not supported in Firefox (I tested with Firefox 108.0.2)

You can test this behavior in https://fetch-flow-control-demo.glitch.me/

And there are related issues here:

Actual results:

No matter we fetch with { cache: 'no-store' }, or we provide response with header Cache-Control: no-store. The backpressure does not take effect, the browser will try to download it all.

Expected results:

If we are not reading from the response, the browser should stop download. If we read 500KB and then stopped, the browser should download >= 500KB and then stop.

valentin - P3/S3 sound right? If no, please change

Severity: -- → S3
Flags: needinfo?(valentin.gosu)
Priority: -- → P3
Whiteboard: [necko-triaged]

The user agent may either accept or ignore the suspension request.

Yes, the wording isn't very strong here.
I think the problem is that we still sometimes store no-store responses in memory (or perhaps we don't, and we have a different back pressure issue). We should take a look eventually, but this does not seem like a high priority.

Blocks: fetch
Flags: needinfo?(valentin.gosu)
You need to log in before you can comment on or make changes to this bug.