Contact emails
yhi...@chromium.org, igrigorik@chromium.org
Spec
- https://fetch.spec.whatwg.org/#request-keepalive-flag
- https://fetch.spec.whatwg.org/#dom-request-keepalive
- https://fetch.spec.whatwg.org/#dom-requestinit-keepalive
Summary
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/AUAIHVF63SM
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
Nothing
Risks
Interoperability and Compatibility
Edge: Positive based on a conversation between Ilya and Todd. Their Beacon implementation is already on top of Fetch and he hinted that it will be quick and easy for them to expose.
Firefox: No signals
https://bugzilla.mozilla.org/show_bug.cgi?id=1342484
Safari: They have implemented (and shipped) the property in Request class, but it looks they haven't implemented the feature itself.
https://bugs.webkit.org/show_bug.cgi?id=168865
https://bugs.webkit.org/show_bug.cgi?id=175482
https://bugs.webkit.org/show_bug.cgi?id=175151
We have some restrictions for the feature:
1. It's disabled on requests which need CORS preflight. Making fetch for such a request
leads to a failure.
2. The feature is disabled on workers.
Ergonomics
Activation
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
Contact emails
yhi...@chromium.org, igrigorik@chromium.org
Spec
- https://fetch.spec.whatwg.org/#request-keepalive-flag
- https://fetch.spec.whatwg.org/#dom-request-keepalive
- https://fetch.spec.whatwg.org/#dom-requestinit-keepalive
Summary
By setting the keepalive flag, a developer can make a fetch which will continue working even when a frame is detached. A web developer can use the feature to report events, state updates and analytics with small amount of data even when the page is about to be unloaded. This is useful for analytics and other cases where async delivery of data is required without blocking navigations, and lessens the need for synchronous XHR which is bad for user experience.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/AUAIHVF63SM
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
Nothing
Risks
Interoperability and Compatibility
Edge: Positive based on a conversation between Ilya and Todd. Their Beacon implementation is already on top of Fetch and he hinted that it will be quick and easy for them to expose.
Firefox: No signals
https://bugzilla.mozilla.org/show_bug.cgi?id=1342484
Safari: They have implemented (and shipped) the property in Request class, but it looks they haven't implemented the feature itself.https://bugs.webkit.org/show_bug.cgi?id=168865
We have some restrictions for the feature:
1. It's disabled on requests which need CORS preflight. Making fetch for such a request
leads to a failure.
2. The feature is disabled on workers.
Ergonomics
Activation
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
- https://wpt.fyi/fetch/api/request/request-keepalive.html
- https://wpt.fyi/fetch/api/request/request-keepalive-quota.html
- https://wpt.fyi/fetch/api/basic/keepalive.html
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HeJDdSgfSdcN4zhrYGJSrF4PnodeZMm32JG5_PAbPHMA%40mail.gmail.com.
On Wed, Jan 3, 2018 at 12:45 PM Yutaka Hirano <yhi...@chromium.org> wrote:Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
- https://wpt.fyi/fetch/api/request/request-keepalive.html
- https://wpt.fyi/fetch/api/request/request-keepalive-quota.html
- https://wpt.fyi/fetch/api/basic/keepalive.htmlI couldn't find a test that makes sure that the request is in fact kept alive after its frame was detached. Is there one? If not, could you add such a test?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaChSeKHvpoWWaXK64bfj5zQ_KPuMNXrYio%3D6E%2Bw%2BdBicg%40mail.gmail.com.
We have some restrictions for the feature:
1. It's disabled on requests which need CORS preflight. Making fetch for such a request
leads to a failure.
2. The feature is disabled on workers.
Are those restrictions documented? Are they part of the spec?If not - could you elaborate on the reasoning for them?
Ergonomics
Activation
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
- https://wpt.fyi/fetch/api/request/request-keepalive.html
- https://wpt.fyi/fetch/api/request/request-keepalive-quota.html
- https://wpt.fyi/fetch/api/basic/keepalive.htmlI couldn't find a test that makes sure that the request is in fact kept alive after its frame was detached. Is there one? If not, could you add such a test?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Microsoft Edge was the first browser to implement fetch with keepalive. It was shipped in Edge 15 in the Windows 10 Creator’s Update in spring 2017.
https://github.com/whatwg/fetch/pull/419 is Ilya’s PR that goes over the quotas that Edge implements.
If further quotas are added or if quotas are loosened, lets please get them into the public fetch spec to ensure websites can easily work across UAs.
-Todd
To unsubscribe from this group and stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6Hq4mcppQAtsJHP3C-BqmED84evjamc8oHVWOSdZU_vCA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
requests with keepalive set works as follows in workers:1. The request will be rejected when there are too many inflight bytes (spec conformant).2. The request will be canceled when the worker is terminated (not spec conformant).So, "keepalive fetch rejects in workers" is not correct.On service workers, evt.respondWith(fetch(evt.request)) will keep the service worker alive for a certain time (regardless of keepalive flag), so it works like keepalive specified.+horo@, please correct me if I'm wrong.
On Fri, Jan 5, 2018 at 10:45 AM, Ben Kelly <bke...@mozilla.com> wrote:On Thu, Jan 4, 2018 at 10:10 AM, Yutaka Hirano <yhi...@chromium.org> wrote:On Thu, Jan 4, 2018 at 12:15 AM, Ben Kelly <bke...@mozilla.com> wrote:On Wed, Jan 3, 2018 at 7:28 AM, Yoav Weiss <yo...@yoav.ws> wrote:On Wed, Jan 3, 2018 at 12:45 PM Yutaka Hirano <yhi...@chromium.org> wrote:Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
- https://wpt.fyi/fetch/api/request/request-keepalive.html
- https://wpt.fyi/fetch/api/request/request-keepalive-quota.html
- https://wpt.fyi/fetch/api/basic/keepalive.htmlI couldn't find a test that makes sure that the request is in fact kept alive after its frame was detached. Is there one? If not, could you add such a test?It would also be nice to have a test verifying that the value is reflected in the service worker `FetchEvent.request` properly.That is tested by https://wpt.fyi/service-workers/service-worker/fetch-event.https.html.Thanks!How do you handle pass-through service worker that does `evt.respondWith(fetch(evt.request))` for keepalive requests? Does that fail since keepalive fetch rejects in workers?Just curious. Thanks again.Ben
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GguqC9kBFHXeHGv1_CC_xCbFdqQtu6hH20RgjM_Mjj6g%40mail.gmail.com.
requests with keepalive set works as follows in workers:1. The request will be rejected when there are too many inflight bytes (spec conformant).2. The request will be canceled when the worker is terminated (not spec conformant).So, "keepalive fetch rejects in workers" is not correct.On service workers, evt.respondWith(fetch(evt.request)) will keep the service worker alive for a certain time (regardless of keepalive flag), so it works like keepalive specified.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6Gs2_Dqzs0s%2BiND6rmKYC3zHttCH0Vw9wbs70Lz%2BQbePQ%40mail.gmail.com.
Hi,I think there are still two remaining issue blocking this intent:* Consensus on whether the spec should encode quotas for maximum amount of work, and how much of that must be reflected in our implementation. I'm thinking of the comments made by Daniel and Todd in particular. (Also, independent of this approval process, I think you should get consensus from Chrome networking experts that the limits and quotas in place are sufficient to prevent abuse.)
* Whether feature detection is broken by Safari's current behavior, and what to do about it to ensure a workable rollout.
friendly ping :)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HeJDdSgfSdcN4zhrYGJSrF4PnodeZMm32JG5_PAbPHMA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Fri, Jan 12, 2018 at 6:15 PM Chris Harrelson <chri...@chromium.org> wrote:Hi,I think there are still two remaining issue blocking this intent:* Consensus on whether the spec should encode quotas for maximum amount of work, and how much of that must be reflected in our implementation. I'm thinking of the comments made by Daniel and Todd in particular. (Also, independent of this approval process, I think you should get consensus from Chrome networking experts that the limits and quotas in place are sufficient to prevent abuse.)yhirano@ - Could you open an issue on the fetch spec asking if we should add quotas on the maximum number of requests, on top of the ones we have in place for the maximum number of bytes?
friendly ping :)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HeJDdSgfSdcN4zhrYGJSrF4PnodeZMm32JG5_PAbPHMA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Regarding sendBeacon(), is https://w3c.github.io/beacon/ the current spec?
It seems to refer to keepalive and make reference to the fact that UAs can set limits - so doesn't that mean that sendBeacon() naturally inherits the limits of what we're discussing here, and we should put in safeguards and limits?
What I'm having trouble to understand is how shipping Fetch Keep Alive makes the situation amy worse? AFAICT, Fetch KeepAlive doesn't provide anything new over sendBeacon within the context of the abuse scenario. Please explain.
What I do know is that by not shipping it we are blocking usage that would make a positive impact for our users.
Should we address the concern? Yes, but not as if it was a P0, launch blocker. It's not, otherwise we should immediately unship sendBeacon and address similar concerns* in other places at a P0 priority. Is there data to support that call?
* AFAIK, DoS can also be done without sendBeacon. The only difference is the "up to 30s bad time after closing a tab" aspect. But, if we are concerned about nefarious actors, they have ways to get in the way of the user gesture to close a tab, making the 30s difference a weak argument to single out sendBeacon. What sorts of mitigations do we have in place for the general case?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvZbgxOzcXbsd%3DNLwK587Fbpj1Hj5gJMmDXdAiLf%3D0pXjg%40mail.gmail.com.
What I'm having trouble to understand is how shipping Fetch Keep Alive makes the situation amy worse? AFAICT, Fetch KeepAlive doesn't provide anything new over sendBeacon within the context of the abuse scenario. Please explain.
What I do know is that by not shipping it we are blocking usage that would make a positive impact for our users.
Should we address the concern? Yes, but not as if it was a P0, launch blocker. It's not, otherwise we should immediately unship sendBeacon and address similar concerns* in other places at a P0 priority. Is there data to support that call?
* AFAIK, DoS can also be done without sendBeacon.
The only difference is the "up to 30s bad time after closing a tab" aspect.
But, if we are concerned about nefarious actors, they have ways to get in the way of the user gesture to close a tab, making the 30s difference a weak argument to single out sendBeacon. What sorts of mitigations do we have in place for the general case?
On Wed, Jan 24, 2018 at 3:35 PM, Kenji Baheux <kenji...@google.com> wrote:What I'm having trouble to understand is how shipping Fetch Keep Alive makes the situation amy worse? AFAICT, Fetch KeepAlive doesn't provide anything new over sendBeacon within the context of the abuse scenario. Please explain.
So it sounds like you're saying my summary is correct?
What I do know is that by not shipping it we are blocking usage that would make a positive impact for our users.
Because we should be focusing on fixing bugs that cause a browser DoS over shipping new features, if we've got bugs that allow arbitrary content to cause a browser DoS. Our triage process is to put the user first
|
On Thu, Jan 25, 2018, 5:50 AM Ryan Sleevi <rsl...@chromium.org> wrote:On Wed, Jan 24, 2018 at 3:35 PM, Kenji Baheux <kenji...@google.com> wrote:What I'm having trouble to understand is how shipping Fetch Keep Alive makes the situation amy worse? AFAICT, Fetch KeepAlive doesn't provide anything new over sendBeacon within the context of the abuse scenario. Please explain.
So it sounds like you're saying my summary is correct?This is the most important point.In my world, which could be flawed, I see:1. A net positive and no extra harm caused by shipping this feature.2. A lack of evidence that shipping Fetch KeepAlive would make things worse.3. A lack of evidence and data that this is already a p0 issue which would justify not only blocking this feature but also disabling sendBeacon. Given that, for the purpose of the abuse scenario, these two are interchangeable, I don't see an valid argumentation where we would be blocked here while keeping sendBeacon enabled. If you think this is indeed a P0 concern, I would like to see an intent to (temporarily) unship sendBeacon while we figure out a solution.
What I do know is that by not shipping it we are blocking usage that would make a positive impact for our users.
Because we should be focusing on fixing bugs that cause a browser DoS over shipping new features, if we've got bugs that allow arbitrary content to cause a browser DoS. Our triage process is to put the user firstThe triage process has a prioritization step. It seems that we have decided to shortcircuit it here.
On Wed, Jan 24, 2018 at 4:16 PM, Kenji Baheux <kenji...@google.com> wrote:On Thu, Jan 25, 2018, 5:50 AM Ryan Sleevi <rsl...@chromium.org> wrote:On Wed, Jan 24, 2018 at 3:35 PM, Kenji Baheux <kenji...@google.com> wrote:What I'm having trouble to understand is how shipping Fetch Keep Alive makes the situation amy worse? AFAICT, Fetch KeepAlive doesn't provide anything new over sendBeacon within the context of the abuse scenario. Please explain.
So it sounds like you're saying my summary is correct?This is the most important point.In my world, which could be flawed, I see:1. A net positive and no extra harm caused by shipping this feature.2. A lack of evidence that shipping Fetch KeepAlive would make things worse.3. A lack of evidence and data that this is already a p0 issue which would justify not only blocking this feature but also disabling sendBeacon. Given that, for the purpose of the abuse scenario, these two are interchangeable, I don't see an valid argumentation where we would be blocked here while keeping sendBeacon enabled. If you think this is indeed a P0 concern, I would like to see an intent to (temporarily) unship sendBeacon while we figure out a solution.I think we may be heading down an unproductive line, or it may be generating unnecessary hostility or frustration.
My goal is not to block your work, and I understand this feature is seen as important. During the review of the spec, concerns were identified. The reviewers of the spec are not as familiar with the code as you are, and what mitigations may exist, and whether the spec concerns are born out in the implementation.I'm hoping we can find a collaborative way in which the implementors of sendBeacon and keepAlive in Chrome can review these concerns, and assess whether we have a risk here. I think the "evidence and data" part falls to the implementors, when the spec itself has this issue. Further, in discussions about the spec, it seems there's some cross-browser support for adding limits that are allowed to be implementation defined - so someone who owns the spec work should be proposing changes to do that, and that own the implementation to make sure we're implementing reasonable limits.Our review process is to try to get actionable feedback, and I fear we've spent more time discussing the relative prioritization than it would take to add some basic limits or review the code for mitigations.
On Wed, Jan 24, 2018, 11:56 PM Ryan Sleevi <rsl...@chromium.org> wrote:I'm having trouble following this logic, but it's unclear if the proposal is:1) We shipped sendBeacon() in a way that can cause a browser DoS
2) When reviewing Fetch API, folks noticed it could cause a browser DoS
3) We should ship Fetch API anyways, because no one noticed this when we shipped sendBeacon(), so what's another browser DoS?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EHGrvkpjnx-xF4aCAYsjJ1voLo_pEb30i7SZStBPMW6g%40mail.gmail.com.
There is even some precedent for that limit. sendBeacon was launched without these limits, but that's a bug in sendBeacon. It shipped because of <a ping> as precedent, and <a ping> imposes a natural limit of one request! That sendBeacon forgot to carry it over is a bug in sendBeacon we need to fix, not an allowance for keepalive.
A limit of one in-flight request seems like something that won't be tenable for the use-cases we want to tackle.I was talking to a third-party provider the other day and they have not switched to sendBeacon due to a bug where the quota was imposed on overall bytes rather than inflight bytes, and the fact that other third parties often ate up their quota.Setting an unrealistically harsh limit won't break sites, but will make sure that third party providers continue to use sync XHR, which is not a desired outcome.
On Thu, Jan 25, 2018 at 10:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:A limit of one in-flight request seems like something that won't be tenable for the use-cases we want to tackle.I was talking to a third-party provider the other day and they have not switched to sendBeacon due to a bug where the quota was imposed on overall bytes rather than inflight bytes, and the fact that other third parties often ate up their quota.Setting an unrealistically harsh limit won't break sites, but will make sure that third party providers continue to use sync XHR, which is not a desired outcome.I think, depending on the implementation state today, it may actually be a desirable outcome! As much as we dislike sync XHRs (and rightfully so), those adhere to all the limits - and predictability bits - that David has mentioned and we've raised concerns about.I agree that it has other downsides that result in poor user experiences on other dimensions, but in the realm of predictability and stability, it actually seems a better option, based on the information shared so far.
On Thu, Jan 25, 2018 at 11:05 AM Ryan Sleevi <rsl...@chromium.org> wrote:On Thu, Jan 25, 2018 at 10:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:A limit of one in-flight request seems like something that won't be tenable for the use-cases we want to tackle.I was talking to a third-party provider the other day and they have not switched to sendBeacon due to a bug where the quota was imposed on overall bytes rather than inflight bytes, and the fact that other third parties often ate up their quota.Setting an unrealistically harsh limit won't break sites, but will make sure that third party providers continue to use sync XHR, which is not a desired outcome.I think, depending on the implementation state today, it may actually be a desirable outcome! As much as we dislike sync XHRs (and rightfully so), those adhere to all the limits - and predictability bits - that David has mentioned and we've raised concerns about.I agree that it has other downsides that result in poor user experiences on other dimensions, but in the realm of predictability and stability, it actually seems a better option, based on the information shared so far.Agreed. Always always *always* remember that our first priority is to our users. We *cannot* break our promises to our users.I'm curious about this overall bytes vs. inflight bytes "bug". Do you mean that, if I each 1GB bandwidth via sendBeacon, as long as I only trickle its usage in 1kb at a time, it's okay? Overall bytes sounds like *exactly* the desirable limit. Using up 1GB slow or fast is still using up 1GB of the user's bandwidth. If the user has no way to cancel the request, it doesn't matter how fast you're doing it.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBSOSyjurCrCxiKJyNDzKZx5yyefa1Ge%2BQPWDNRhGnmqw%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
> Agreed. Always always *always* remember that our first priority is to our users. We *cannot* break our promises to our users.
Not advocating anything, but the web kind of already did break that promise with service workers that can outlive the tab for ten minutes (or more, with continuous postMessage/onmessage? Or was that resolved already?), or so I have understood or read around here recently.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Kr%2B2PmHf%3Db2RQFrcKhhh1sP9vGGCwfx3BcgiW8ssurPA%40mail.gmail.com.
On Thu, Jan 25, 2018 at 11:05 AM Ryan Sleevi <rsl...@chromium.org> wrote:On Thu, Jan 25, 2018 at 10:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:A limit of one in-flight request seems like something that won't be tenable for the use-cases we want to tackle.I was talking to a third-party provider the other day and they have not switched to sendBeacon due to a bug where the quota was imposed on overall bytes rather than inflight bytes, and the fact that other third parties often ate up their quota.Setting an unrealistically harsh limit won't break sites, but will make sure that third party providers continue to use sync XHR, which is not a desired outcome.I think, depending on the implementation state today, it may actually be a desirable outcome! As much as we dislike sync XHRs (and rightfully so), those adhere to all the limits - and predictability bits - that David has mentioned and we've raised concerns about.I agree that it has other downsides that result in poor user experiences on other dimensions, but in the realm of predictability and stability, it actually seems a better option, based on the information shared so far.Agreed. Always always *always* remember that our first priority is to our users. We *cannot* break our promises to our users.
I'm curious about this overall bytes vs. inflight bytes "bug". Do you mean that, if I each 1GB bandwidth via sendBeacon, as long as I only trickle its usage in 1kb at a time, it's okay?
On Fri, Jan 26, 2018 at 4:24 AM, PhistucK <phis...@gmail.com> wrote:> Agreed. Always always *always* remember that our first priority is to our users. We *cannot* break our promises to our users.
Not advocating anything, but the web kind of already did break that promise with service workers that can outlive the tab for ten minutes (or more, with continuous postMessage/onmessage? Or was that resolved already?), or so I have understood or read around here recently.You are right that there is some delay, but service workers are designed to go away once they aren't needed (e.g., tab is closed and they aren't getting legitimate events like push notifications). The specification allows the UA to terminate service workers at any time.
Status update:We had a meeting on this topic, and agreed on the following:A. Have a relatively loose limit on the number of SendBeacon connections (as it's already shipped).B. Have a relatively tight limit on the number of fetch() + keepalive connections (as there is no users yet).C. Update both values and unify them in the future based on UMA data and developer feedback.For C, I added histograms.I will do B next week and will resume this thread after that.
LGTM1
Thanks,
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBSOSyjurCrCxiKJyNDzKZx5yyefa1Ge%2BQPWDNRhGnmqw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Kr%2B2PmHf%3Db2RQFrcKhhh1sP9vGGCwfx3BcgiW8ssurPA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_Taax9P5Nwz%3D7d-7s5FvhQdrDCNfRBPSHYbZc%2BGM3M-w%40mail.gmail.com.
Contact emails
yhi...@chromium.org, igrigorik@chromium.org
Spec
- https://fetch.spec.whatwg.org/#request-keepalive-flag
- https://fetch.spec.whatwg.org/#dom-request-keepalive
- https://fetch.spec.whatwg.org/#dom-requestinit-keepalive
Summary
By setting the keepalive flag, a developer can make a fetch which will continue working even when a frame is detached. A web developer can use the feature to report events, state updates and analytics with small amount of data even when the page is about to be unloaded. This is useful for analytics and other cases where async delivery of data is required without blocking navigations, and lessens the need for synchronous XHR which is bad for user experience.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/AUAIHVF63SM
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Debuggability
Nothing
Risks
Interoperability and Compatibility
Edge: Positive based on a conversation between Ilya and Todd. Their Beacon implementation is already on top of Fetch and he hinted that it will be quick and easy for them to expose.
Firefox: No signals
https://bugzilla.mozilla.org/show_bug.cgi?id=1342484
Safari: They have implemented (and shipped) the property in Request class, but it looks they haven't implemented the feature itself.https://bugs.webkit.org/show_bug.cgi?id=168865
https://bugs.webkit.org/show_bug.cgi?id=175482
https://bugs.webkit.org/show_bug.cgi?id=175151
We have some restrictions for the feature:
1. It's disabled on requests which need CORS preflight. Making fetch for such a request
leads to a failure.
2. The feature is disabled on workers.
Ergonomics
Activation
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Web platform tests:
- https://wpt.fyi/fetch/api/request/request-keepalive.html
- https://wpt.fyi/fetch/api/request/request-keepalive-quota.html
- https://wpt.fyi/fetch/api/basic/keepalive.html
> We have some restrictions for the feature:
> 1. It's disabled on requests which need CORS preflight. Making fetch for such a requestAs Out-of-Renderer CORS (OOR-CORS) is rolling out, we are ready to remove this restriction.I'm going to support CORS preflight on M81.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0fb00d1e-ad24-48c6-8139-1befd229dbf4%40chromium.org.