Specify restriction for requests with keepalive set #679

yutakahirano · 2018-03-06T09:27:55Z

Problem

We, Chrome, shipped the keepalive flag in fetch API, with a non-interoperable restrictions:

If the renderer process is processing more than 9 requests with keepalive set, we reject a new request with keepalive set initiated by fetch().
If the renderer process is processing more than 19 requests with keepalive set, we reject a new request with keepalive set.
- Note: The difference between fetch() + keepalive vs. SendBeacon is from a historical reason and we are going to have a unified restriction.
If Chrome is processing more than 255 requests with keepalive set, we reject a new request with keepalive set.

These restrictions are very much visible to web developers (making 10 fetch requests is very easy), so we would like to replace them with an interoperable ones, if possible.

What’s special about keepalive?

Chrome is a multi-tab applications, and many resources (CPU, memory, network, …) are associated with tab. For example, it is easy to create a non-responding web application like this.

<html>
<head>
<script>while(true) {}</script>
</html>

But a user can free up the CPU resource by simply closing the tab without impacting other web pages (or tabs) negatively. That is also true for network resources. Web pages can issue many network requests, but they will be cancelled when the page is unloaded or killed forcibly.

Requests with keepalive set is an exception. As stated in the fetch spec, requests with keepalive set survive page unload. This is a kind of resource leak from the above POV; the request is still ongoing while the tab is closed, and we don’t have a means to abort it except for shutting down the entire browser.

Mitigations

Chrome has some mitigations for the problem.

Upload payload size [specced]

As written in the spec, we only allow 64KiB payload per fetch group at a time. Unfortunately, this restriction is easy to escape.

Timeout [chrome only]

Requests with keepalive set will be cancelled when 30 seconds passed since the associated context (mostly frame) is destroyed.

Number of requests per process [chrome only]

The number of requests with keepalive set per render process is restricted in Chrome. This restriction is hard to escape but we cannot have is in the spec because “renderer process” is Chrome-only concept. We also have some uncertainty because sometimes a renderer process can be shared.

Number of requests per browser [chrome only]

The number of requests with keepalive set is restricted in Chrome. This restriction is impossible to escape as long as you are using the browser.

Abort request after the response is received [chrome only]

Chrome aborts a request with keepalive when both of the following hold:
The associated context has already been destroyed.
The response has already been received.
This prevents mass download after the tab is closed.

Interoperability

I think having interoperability here is particularly good from two reasons.

One is to have a unified policy. Given the leaky nature of the flag, each implementer has to make a balanced decision between developers’ convenience and users’ expectation. Having diverse policies will confuse both developers and users.

The other is the difficulty to handle errors. keepalive flag is expected to be used when the page is about to unload. In such a circumstance developers are not likely to be able to detect and handle errors correctly. Having a rigid, interoperable restrictions will be developers’ benefit.

Proposal

The policy we would have should have the following properties:

It is difficult for (evil) web developers to circumvent the restrictions without being noticed by end users.
It should be aligned with reasonable end user expectations.

Here I propose the following:

Introduce KeepaliveContext which keeps track of the inflight requests with keepalive set.
- A unit of related browsing contexts share a KeepaliveContext.
- A dedicated worker shares the KeepaliveContext with its responsible browsing context.
- A shared Worker shares the KeepaliveContext with its responsible browsing context.
- Service worker: TBD; see below.
Restrict the number of inflight request with keepalive set asynchronously in a KeepaliveContext. Put a number that all implementations should allow.
Restrict the total number of inflight body size with keepalive set asynchronously in a KeepaliveContext. Note that this changes https://w3c.github.io/beacon/#sec-processing-model which contains a synchronous check.
Cancel a request with keepalive set when a certain time period passed from the fetch group termination.
Cancel a request with keepalive when both of the following hold:
- The associated fetch group has already been terminated.
- The response has already been received.

Service Worker

A web developer can create multiple service workers by using iframes, so assign one KeepaliveContext for each service worker is not an option. Here are some ideas:

Have a global KeepaliveContext used by all service workers

This should work, but it will be too restrictive.

Use the first service worker client’s KeepaliveContext

This can be leaky in some pathological cases. This will be a bit unintuitive.

A service worker intercepted request keeps KeepAliveContext

(proposed by @ricea )

A requested initiated by a service worker is not protected, but a request coming from a page is protected by the KeepAliveContext for the original request.

Do nothing; Let the service worker keep itself alive

The spec says:

A user agent may terminate service workers at any time it:

Has no event to handle.

Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events.

When detecting a abnormal operation, it makes sense to cancel the request even with keepalive set. That means, If we are interested in requests with keepalive set from the page, they should be protected by the service worker.
This option disables keepalive protection in service workers.

I (@yutakahirano) like the last option.

The text was updated successfully, but these errors were encountered:

yutakahirano · 2018-03-06T09:32:29Z

@annevk @yoavweiss @igrigorik @sleevi @davidben
@wanderview @youennf @toddreifsteck

annevk · 2018-03-07T01:47:02Z

KeepaliveContext is just a concept, not an API, right?

yutakahirano · 2018-03-07T02:02:37Z

KeepaliveContext is just a concept, not an API, right?

It's just a concept.

yutakahirano · 2018-03-22T04:43:44Z

Does anyone have any feedback?

yutakahirano · 2018-04-05T04:16:23Z

Does anyone have any feedback?

ricea · 2018-04-05T09:48:44Z

So, from Chrome's perspective, a KeepAliveContext would replace the per-renderer restrictions?

Does this mean doing away with the 30 second timeout in Chrome? Could we at least apply an equivalent timeout to a ServiceWorker, so a page can't create a keepalive request that lives longer than a ServiceWorker could perform the equivalent fetch?

I also like the "keepalive does nothing in ServiceWorkers" approach, although it might confuse developers. Presumably if a keepalive is forwarded through a ServiceWorker it gets added to the KeepAliveContext for the page it came from?

youennf · 2018-04-05T16:46:24Z

The number of request per process might be difficult to handle for developers and might never be interoperable anyway.
Number of requests per browser might be interoperable but one can argue that the actual limitation might depend on the actual configuration of the device.

It makes sense to me to limit keep alive requests according their clients/workers origin and not in terms of context or process.
Clients/workers can coordinate if they do not want to hit the limit.
For WebKit, the context could be double-keyed for privacy reasons.

For keep alive requests, WebKit is defining a long timeout after which request is aborted.
We could try to be consistent across browsers.

Or we could have no timeout at all for these requests as long as the context of the request exists.
We would then use an abort timeout when the context of the keep alive request is being destroyed.
That way, a user could expect that closing a tab will eventually kill the related keep alive requests after some grace period. Not sure the timeout actually needs to be specified.

FWIW, this timeout-on-destruction is close to how WebKit is handling service workers.
When there is no more clients that a service worker can talk to, the service workers get killed after a grace period.

yutakahirano · 2018-04-06T05:21:20Z

So, from Chrome's perspective, a KeepAliveContext would replace the per-renderer restrictions?

Yes.

Does this mean doing away with the 30 second timeout in Chrome? Could we at least apply an equivalent timeout to a ServiceWorker, so a page can't create a keepalive request that lives longer than a ServiceWorker could perform the equivalent fetch?

No, it should be covered by "Cancel a request with keepalive set when a certain time period passed from the fetch group termination."

I also like the "keepalive does nothing in ServiceWorkers" approach, although it might confuse developers. Presumably if a keepalive is forwarded through a ServiceWorker it gets added to the KeepAliveContext for the page it came from?

Could you tell me why it's confusing?
Your proposal is very interesting. I'll add it to the options.

yutakahirano · 2018-04-06T05:30:12Z

The number of request per process might be difficult to handle for developers and might never be interoperable anyway.

Agreed.

Number of requests per browser might be interoperable but one can argue that the actual limitation might depend on the actual configuration of the device.

I'd add one more reason against this option: giving an ability to exhaust entire limit to each evil developer is not desirable.

It makes sense to me to limit keep alive requests according their clients/workers origin and not in terms of context or process.
Clients/workers can coordinate if they do not want to hit the limit.
For WebKit, the context could be double-keyed for privacy reasons.

It's very easy to create a cross-origin iframe (e.g., www.example.com and www2.example.com) and that's why I'd like to use a top-level frame as a basic unit instead of origin.

For keep alive requests, WebKit is defining a long timeout after which request is aborted.
We could try to be consistent across browsers.

Thank you, that's really encouraging.

Or we could have no timeout at all for these requests as long as the context of the request exists.
We would then use an abort timeout when the context of the keep alive request is being destroyed.
That way, a user could expect that closing a tab will eventually kill the related keep alive requests after some grace period. Not sure the timeout actually needs to be specified.

That's what Chrome is doing. I'm not sure if the specific timeout value should be specified either, but describing a mechanism will be good.

FWIW, this timeout-on-destruction is close to how WebKit is handling service workers.
When there is no more clients that a service worker can talk to, the service workers get killed after a grace period.

ricea · 2018-04-06T13:55:04Z

I also like the "keepalive does nothing in ServiceWorkers" approach, although it might confuse developers.

Could you tell me why it's confusing?

I'm concerned that if it appears to work but sometimes doesn't, developers might be surprised.

However, I haven't come up with any case where this really matters. I don't think we need to worry about it.

yutakahirano · 2018-09-20T05:21:46Z

I proposed a session for this topic at https://www.w3.org/wiki/TPAC/2018/SessionIdeas#Session:_restriction_for_fetch_keepalive. I'm looking forward to see you there.

yutakahirano · 2018-10-24T15:23:55Z

https://docs.google.com/document/d/1OBubpZkvxB9WioVAnfK_Fn5up_8E9o6hqX7NN0LJENY/edit

mfalken · 2018-10-27T07:37:44Z

(we talked about this offline but I wanted to have a record) It would not be good for keepalive to have no effect in service workers, especially for requests that are initiated by the worker. See w3c/ServiceWorker#1336 for a use case.

In the notes from #679 (comment) I believe the summary wrt to service workers is:

Keepalive requests from a service worker should be respected in some way.
Fetch requests with keepalive should not skip the controller service worker (a bit orthogonal to the question of whether keepalive from service worker should be respected)

yutakahirano · 2018-10-29T08:37:30Z

Based on what we discussed at TPAC, I update the proposal as following:

Introduce KeepaliveContext which keeps track of the inflight requests with keepalive set.
Each origin has its own KeepaliveContext.
Each browsing context has its associated KeepaliveContext.
If a browsing context is a top-level browsing context, its KeepaliveContext is set to its origin's KeepaliveContext.
If a browsing context is a nested browsing context, its KeepaliveContext is set to its parent browsing context's KeepaliveContext.
A dedicated worker shares the KeepaliveContext with its responsible browsing context.
All service workers and shared workers share one KeepaliveContext.
A request has an associated KeepaliveContext. It is set to
- the original request's KeepaliveContext for the service worker interception case, and
- client's KeepaliveContext otherwise.
When a fetch group is terminated, for each request r with keepalive set:
1. Let context be r's associated KeepaliveContext.
2. If the size of context doesn't exceed a certain limit, then add r to context.
3. Otherwise, abort r.

Makes sense?

youennf · 2018-10-29T13:04:05Z

I think this captures where we want to go.

We should be able to update the spec so that:

keep alive requests attached to a browsing context do not have restriction
keep alive requests that are no longer attached to a browsing context may be restricted.

I am hesitant to describe more than that given that:

implementations might not be able to agree on the definition of the KeepAlive context.
the user agent might be more restrictive in some cases like low power mode or memory pressure.

mfalken · 2018-10-30T01:58:49Z

#679 (comment) makes sense to me to implement. Like Youenn, I'm not quite convinced the specification needs this level of detail, but I'll leave it for you.

The updated proposal doesn't seem to include the 30 second timeout. Is it being removed?

By the way, don't these restrictions conflict with the current Beacon spec? Beacon is specified using keepalive and says:

[Other than payload size], the sendBeacon() API is not subject to any additional restrictions. The user agent ought not skip or throttle processing of sendBeacon() calls, as they can contain critical application state, events, and analytics data.

yutakahirano · 2018-10-31T10:12:30Z

@youennf I think it's valuable to have a policy in the spec, as said in the original proposal.

I think having interoperability here is particularly good from two reasons.

One is to have a unified policy. Given the leaky nature of the flag, each implementer has to make a balanced decision between developers’ convenience and users’ expectation. Having diverse policies will confuse both developers and users.

The other is the difficulty to handle errors. keepalive flag is expected to be used when the page is about to unload. In such a circumstance developers are not likely to be able to detect and handle errors correctly. Having a rigid, interoperable restrictions will be developers’ benefit.

I think it's good to leave actual numbers hand-wavy. We can replace 9 in #679 (comment) with something like:

When a fetch group is terminated, for each request r with keepalive set:

Let context be r's associated KeepaliveContext.
Add r to context.
User agent may abort r based on the number of requests in context whose done flag is not set.
User agent may abort r based on the number of requests in all KeepaliveContexts whose done flag is not set.
User agent may abort r after certain time passed.

youennf · 2018-11-01T10:23:38Z

A side note: if we decide to remove the 64KB restriction for attached keep alive requests, we might still want to warn developers that long keep alive uploads have higher chance to fail. Hence advise to keep these requests as small as possible.

MayyaSunil · 2024-08-01T10:12:44Z

Hello @yutakahirano, @mfalken

We’re excited to share that Firefox is rolling out a new feature soon, and we’re aiming to include similar resource restrictions.


    - If the renderer process is processing more than 9 requests with keepalive set, we reject a new request with keepalive set initiated by fetch().
    - If the renderer process is processing more than 19 requests with keepalive set, we reject a new request with keepalive set.
        Note: The difference between fetch() + keepalive vs. SendBeacon is from a historical reason and we are going to have a unified restriction.
    - If Chrome is processing more than 255 requests with keepalive set, we reject a new request with keepalive set.

Could you let me know if these restrictions have changed?
While we’re taking a slightly different route by limiting them based on origin and restricting requests per browser instance, we want to keep our limits comparable to Chrome’s.

By the way, what’s the plan for addressing the spec issue?

Thanks a million!

ricea · 2024-08-05T04:28:29Z

Neither @yutakahirano nor @mfalken work on Chrome any more. Pinging @mingyc who has been touching keepalive as part of them deferred fetch work.

mingyc · 2024-11-12T07:27:14Z

The current keepaive-specific limits have been updated for a while:

Maximum pending fetch keeaplive requests across Chrome: 2048
Maxium pending fetch keepalive requests for a top-level frame (a Chrome-specific concept that usually maps to a top-level document in a different process, see also RenderFrameHost): 256
Maxium allowed accumulated fetch keepalive request size within a top-level frame: 512 * 1024.

The Chromium source is here.

mfalken mentioned this issue Oct 24, 2018

No good way to beacon during activate w3c/ServiceWorker#1336

Open

szmarczak mentioned this issue Feb 6, 2020

Duplicate retries when using Chromium sindresorhus/ky#233

Open

fowl2 mentioned this issue Jan 8, 2022

Flag for "Terminate on Response Body"? #1382

Open

hpohlmeyer mentioned this issue Sep 9, 2022

feat: add SendBeaconInterceptor mswjs/interceptors#284

Open

kuhe mentioned this issue Oct 10, 2023

fix: default keepalive=false for fetch smithy-lang/smithy-typescript#1016

Merged

zcorpan mentioned this issue Jan 24, 2024

Fetch keepalive mozilla/standards-positions#967

Closed

jthrilly mentioned this issue Mar 1, 2024

Fix: Interview Export Errors complexdatacollective/Fresco#90

Merged

j7i mentioned this issue Oct 16, 2024

Tracker Version v4: Pending Fetch API Requests Accumulating in OutQueue on Chrome snowplow/snowplow-javascript-tracker#1355

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Specify restriction for requests with keepalive set #679

Specify restriction for requests with keepalive set #679

yutakahirano commented Mar 6, 2018 •

edited

Loading

yutakahirano commented Mar 6, 2018

annevk commented Mar 7, 2018

yutakahirano commented Mar 7, 2018

yutakahirano commented Mar 22, 2018

yutakahirano commented Apr 5, 2018

ricea commented Apr 5, 2018

youennf commented Apr 5, 2018

yutakahirano commented Apr 6, 2018

yutakahirano commented Apr 6, 2018 •

edited

Loading

ricea commented Apr 6, 2018

yutakahirano commented Sep 20, 2018 •

edited

Loading

yutakahirano commented Oct 24, 2018

mfalken commented Oct 27, 2018

yutakahirano commented Oct 29, 2018

youennf commented Oct 29, 2018

mfalken commented Oct 30, 2018

yutakahirano commented Oct 31, 2018

youennf commented Nov 1, 2018

MayyaSunil commented Aug 1, 2024 •

edited

Loading

ricea commented Aug 5, 2024

mingyc commented Nov 12, 2024

Specify restriction for requests with keepalive set #679

Specify restriction for requests with keepalive set #679

Comments

yutakahirano commented Mar 6, 2018 • edited Loading

Problem

What’s special about keepalive?

Mitigations

Upload payload size [specced]

Timeout [chrome only]

Number of requests per process [chrome only]

Number of requests per browser [chrome only]

Abort request after the response is received [chrome only]

Interoperability

Proposal

Service Worker

Have a global KeepaliveContext used by all service workers

Use the first service worker client’s KeepaliveContext

A service worker intercepted request keeps KeepAliveContext

Do nothing; Let the service worker keep itself alive

yutakahirano commented Mar 6, 2018

annevk commented Mar 7, 2018

yutakahirano commented Mar 7, 2018

yutakahirano commented Mar 22, 2018

yutakahirano commented Apr 5, 2018

ricea commented Apr 5, 2018

youennf commented Apr 5, 2018

yutakahirano commented Apr 6, 2018

yutakahirano commented Apr 6, 2018 • edited Loading

ricea commented Apr 6, 2018

yutakahirano commented Sep 20, 2018 • edited Loading

yutakahirano commented Oct 24, 2018

mfalken commented Oct 27, 2018

yutakahirano commented Oct 29, 2018

youennf commented Oct 29, 2018

mfalken commented Oct 30, 2018

yutakahirano commented Oct 31, 2018

youennf commented Nov 1, 2018

MayyaSunil commented Aug 1, 2024 • edited Loading

ricea commented Aug 5, 2024

mingyc commented Nov 12, 2024

yutakahirano commented Mar 6, 2018 •

edited

Loading

yutakahirano commented Apr 6, 2018 •

edited

Loading

yutakahirano commented Sep 20, 2018 •

edited

Loading

MayyaSunil commented Aug 1, 2024 •

edited

Loading