Re: [whatwg/fetch] Specify restriction for requests with keepalive set (#679)

> 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 one evil developer to an ability to exhaust entire limit 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/679#issuecomment-379152226