[meta] Support Fetch keepalive flag and enforce limit on inflight keepalive bytes
Categories
(Core :: DOM: Networking, task, P2)
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
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•6 years ago
|
Comment 2•6 years ago
|
||
I'll defer to asuth on priority since I'm not sure how much of a real world compat issue this is.
Comment 3•6 years ago
|
||
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.
Comment 5•5 years ago
|
||
Dragana - can you take this on?
Comment 6•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•4 years ago
|
Comment 7•4 years ago
|
||
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.
Updated•2 years ago
|
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.
Comment 10•2 years ago
|
||
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.
Updated•1 year ago
|
Comment 11•10 months ago
|
||
Hey guys! Is there any hope that we will ever be able to use this feature in Firefox?
Comment 12•10 months ago
|
||
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.
Comment 13•10 months ago
•
|
||
I think there are two relevant mechanisms here.
- 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.
- 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.
Comment 14•10 months ago
|
||
Hi, everyone! It will be perfect to have this feature in Firefoxe)
Updated•9 months ago
|
Comment 15•5 months ago
|
||
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?
Comment hidden (me-too) |
Updated•3 months ago
|
Updated•2 months ago
|
Comment 17•13 days ago
|
||
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.
Comment 18•16 hours ago
|
||
(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.
Comment 19•13 hours ago
|
||
(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!
Description
•