Re: [fetch] Add flag to indicate delay-tolerant Request, to enable request coalescing. (#184)

> If we let the webpage see the timing of when the request goes out, that will severely limit our flexibility in choosing that timing. And we'll have to precisely define what that timing should be so that it's consistent across browsers.

The webpage will be able to observe when the fetch goes out by checking the [fetchStart](https://w3c.github.io/resource-timing/#widl-PerformanceResourceTiming-fetchStart) timestamp on the associated ResourceTiming object. The delta between [startTime](https://w3c.github.io/resource-timing/#startTime-attribute) and `fetchStart` is the time the request was "blocked" on the client due to unavailable connection (e.g. due to all http/1 connections being occupied), or coalescing delay.

The above doesn't limit us in any way. I do think we should provide some suggested values for how often the UA should flush coalesced requests, but this can be purely advisory.

> On a separate note, what is the plan for if the user leaves the page while these requests are still pending?
> 
> Do they still go out in the background (which is what I believe happens with sendBeacon)?

If the pending request was queued via sendBeacon then yes, they'll be dispatched whenever visibilityChange transitions to 'hidden'.

> Are they "flushed" and go out right away?
> Are then simply dropped on the floor and never sent?
> Do we fire the reject-handler before leaving the page?
> Do we let the webpage choose?

Dropped on the floor and never sent, I think.

- If you need stronger guarantees then you have sendBeacon.
- AFAIK, we don't automatically reject active fetch requests when page is being unloaded.
- We cancel active requests when unloading, firing them doesn't make sense.



---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/184#issuecomment-165868967