Yep, sorry this is not supported now. We have a hard 5 minute limit on keeping service workers alive. This is intended to defend against wasting battery and CPU, especially with respect to badly or maliciously written service workers.

I don't have a plan for what to do here. Would it be possible to download the data in chunks as a workaround?

Jake: this might be an interesting problem to think about. I'm also curious what Firefox and Edge implementations would do.

Firefox has an open bug regarding this exact same issue. They don't support ReadableStreams yet so it is a lower priority for them, but according to the last comment on the bug it sounds like once streams are implemented they will support keeping the service worker alive for longer periods if it is holding a FetchEvent.respondWith() and the FetchEvent's window is still open. If the FetchEvent's window is closed, the respondWith() keep alive will be revoked.

https://bugzilla.mozilla.org/show_bug.cgi?id=1302715

I think ideally the lifetime here would be extended as long as the "outer" fetch being intercepted is still open.  So if the Client is closed it would normally get canceled.  If no data is received it would ideally be timed out for inactivity.  Either of these should remove the lifetime extension.

But this might be a bit complicated for us to implement at the moment.  But I think long term that is where we would like to go.

I guess we would also have to think about things like beacon which don't cancel on Client close.  We don't want those to be used for arbitrary lifetime extension of the SW.

See also https://github.com/jakearchibald/background-fetch which appears designed to meet this type of use case.

I would add that it may be worth distinguishing between proposals to keep the background thread alive after the user browses away from the origin page or closes the browser versus keeping it alive while the user still has the origin page loaded. 

The issue raised here is that even if you keep the origin page loaded the worker gets killed.  

IMO I think background-fetch just adds more complexity and it just gives you yet another way of solving things. I don't really see that much advantages over it. Most of the things can already be handled with the technics we already have today.

The only issue I got with service worker is the hard lifetime limit. You might see it as a defense mechanism. But I see it as blocker.
Some have a good valid reason for keeping the service worker running for a longer time. 
StreamSaver.js is one of them, Another would be webtorrent if webrtc was supported in service worker...

I would rater want the timeout to be removed and instead see some defense mechanism for blocking large cpu/battery/memory/bandwidth draining scripts. 

The NextAction date has arrived: 2017-10-01

The NextAction date has arrived: 2018-03-01

Chrome Remote Desktop is interested in using respondWith() for large data transfers. Is there a path forward for this?

rkjnsn@ could you comment more about priorities/plans here? (maybe internally if you want)

Re-reading this, I'm agreeing with the feature request but there may be complexity here. This could be a medium-sized project for a dedicated contributor.

I think I agree with the end-goal vision expressed in comment #4. It feels like it should be possible to mint a keep alive token when the service worker starts intercepting a resource request and revoke it when the outer resource request completes.

This is probably blocked on refactoring timeouts at issue 852658.