Open Bug 1342484 (fetchKeepAlive) Opened 7 years ago Updated 13 hours ago

[meta] Support Fetch keepalive flag and enforce limit on inflight keepalive bytes

Categories

(Core :: DOM: Networking, task, P2)

task

Tracking

()

People

(Reporter: igrigorik, Unassigned)

References

(Depends on 3 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta, Whiteboard: [necko-triaged])

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

Steps to reproduce:

https://github.com/whatwg/fetch/pull/419

> Requests with keepalive flag set are allowed to outlive the environment
> settings object. We want to make sure that such requests do not
> negatively impact the user experience when a page is unloaded, etc.
> 
> This limits the amount of (body) bytes that can be inflight at any point
> when the request has the keepalive flag set; this flag is set by
> sendBeacon.



Expected results:

Firefox should support the keepalive flag & enforce the inflight byte limit.

p.s. this is also used by sendBeacon: https://github.com/w3c/beacon/pull/39
Component: Untriaged → DOM
Product: Firefox → Core
Priority: -- → P2
Component: DOM → DOM: Networking
Priority: P2 → --
Andrew, how urgent is this? is it still a P2?
Flags: needinfo?(overholt)
I'll defer to asuth on priority since I'm not sure how much of a real world compat issue this is.
Flags: needinfo?(overholt) → needinfo?(bugmail)
I think we want fetch keepalive for our next big wave of SW enhancements.  To restate the situation as I understand it from https://github.com/w3c/ServiceWorker/issues/1336 and others, as well as the ServiceWorker F2F at TPAC is:
- navigator.sendBeacon() is not exposed in ServiceWorkers because the idea was fetch keepalive is the underlying primitive and we should expose just that.
- There is interest from various large sites to be able to send reliable beacons without doing things that would impact the performance of the SW because of concerns about premature SW termination if not protected by a waitUntil.  (In particular, the activation step.)
  - This is of somewhat extra importance given that large sites in particular seem to want to have a panic button that lets them turn off ServiceWorkers across their site based on metrics, etc. and beacons are an important part of their metrics about whether they need to panic or not.  (Clear-Site-Data does help here, but the UX of Clear-Site-Data means that sites are likely to only want to use that as a last resort.)

P2 sounds reasonable to me, but I don't know what the P2's are it's competing with.  It's definitely something that should have an ETA in 2019Q1 or Q2.
Flags: needinfo?(bugmail)
Ok, thanks.
Priority: -- → P2
Whiteboard: [necko-triaged]
Dragana - can you take this on?
Assignee: nobody → dd.mozilla
Flags: needinfo?(dd.mozilla)
I forgot to update this, but we discussed this and no longer think the currently specified keepalive limit makes sense: https://github.com/whatwg/fetch/issues/679.

What would work well for Safari and us (at least per current anti-tracking strategy) is to have a limit on number of keepalive fetches (not necessarily the amount of bytes, but we if count bytes it needs to count headers too) per first-party origin.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(dd.mozilla)
Blocks: fetch

Another use case for fetch keepalive is the ability to handle server errors and allow outliving the environment, without the use of a service worker. Although you can't handle server errors for a request that outlives the environment (without a service worker), it would be nice to have a single API that could handle either scenario (server error OR outlive environment), albeit not at the same time.

Assignee: dd.mozilla → nobody
Status: ASSIGNED → NEW

Hi there, any update on this issue?
The problem is that some adblockers have started blocking Beacon requests so keepalive flag is even more important now.

I'm also very interested in support for this feature. If you discount IE, Firefox is the only browser without support for the keepalive flag since 2019: https://caniuse.com/mdn-api_request_keepalive

My use case:
We're sending metadata to a server, and we want to be certain it's sent even if the page is being unloaded. We don't really care about it's body, but we need to know when the request is complete. Navigator.sendBeacon() supports the former, but not the latter (since we don't get a promise back). Using fetch with keepalive: true ensures both conditions; not being canceled as well as receiving a promise back for when the request is complete.

We can't replace our current Navigator.sendBeacon() usage completely, since Firefox does not support fetch with the keepalive flag. It would be great for Web compatability if this feature was implemented.

Severity: normal → S3

Hey guys! Is there any hope that we will ever be able to use this feature in Firefox?

This would require some reverse engineering to have something compatible with the other browsers (see https://github.com/whatwg/fetch/issues/679), but what is in the spec, https://fetch.spec.whatwg.org, is rather simple.
Valentin, do we already support keepalive type of requests from Necko point of view - requests which stay alive a bit longer than the relevant browsing context or window context?

Though, we would still want to have some keepalive manager in the parent process to limit the number of such requests per origin or so.
Or perhaps something simple like what sendBeacon does would work reasonable well too, one could add a shutdown blocker or some such for the relevant content process.

Flags: needinfo?(valentin.gosu)

I think there are two relevant mechanisms here.

  1. The load group. I think fetch requests go in the loadgroup of the page it's created from, so when that gets unloaded, fetch requests would get cancelled. I think it is definitely possible to have a different loadgroup for keepalive requests, so we don't cancel them on unload.
  2. The channel actors. PHttpChannel is managed by PNecko which is managed by PContent. If the user closes the tab and that destroys PContent, the channels should also get destroyed. Though I'm not 100% sure that is what we do right now. Right now, the signal to close the channel when the tab dies is sent from HttpChannelChild::ActorDestroy so it should be easy to exclude keepalive requests.

A keepalive channel manager would indeed be necessary to enforce the limits and make sure we properly clean up after the channels.

Flags: needinfo?(valentin.gosu)

Hi, everyone! It will be perfect to have this feature in Firefoxe)

Severity: S3 → N/A
Type: defect → task

any updates to this? keepalive is living standard, and firefox already implements a very similar approach with sendBeacon. so i think this should be a rather low-hanging fruit?

Summary: Support Fetch keepalive flag and enforce limit on inflight keepalive bytes → [meta] Support Fetch keepalive flag and enforce limit on inflight keepalive bytes
Depends on: 1871372
Depends on: 1871380
Depends on: 1873549
Alias: fetchKeepAlive
Depends on: 1875674
Depends on: 1875623
Depends on: 1875702

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

(In reply to lena.a.cohen from comment #17)

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Hello Lena,
We have started the implementation for keepalive. You should expect this to be operational within next two releases.

(In reply to Sunil Mayya from comment #18)

(In reply to lena.a.cohen from comment #17)

Hi! Any updates on when the keepalive flag will be supported in Firefox? I can't use sendBeacon for my application because I need to set custom headers, and fetch with keepalive is the only alternative.

Hello Lena,
We have started the implementation for keepalive. You should expect this to be operational within next two releases.

Thank you so much Sunil!

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