27524 2014-12-05 11:02:24 +0000 Queue a fetch task on request's client rather than request? 2015-04-05 11:53:43 +0000 1 1 1 Unclassified WHATWG Fetch unspecified Other other RESOLVED WONTFIX P2 normal Unsorted 1 jungkees annevk bkelly jaffathecake mike nsm.nikhil sideshowbarker+fetchspec oldest_to_newest 115969 0 jungkees 2014-12-05 11:02:24 +0000 Currently, FetchEvent.default(http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#default-method) in Service Worker spec is invoking fetch with the request's synchronous flag set. But we'd like to change it async so that it can run async as self.fetch() method does. A problem lies in queuing a task for running the "process response" steps. Currently, fetch algorithm step 11 executes "Queue a fetch task on *request* to process response for response." In this setting, the process response steps will run in the service worker client's responsible event loop instead of in the ServiceWorkerGlobalScope's responsible event loop. Could you address this such that the process response steps can run in a client (environment settings object)'s responsible event loop? Something like "To queue a fetch task on request's client client to run an operation, queue a task to run an operation on client's responsible event loop using the networking task source." would be great. 115986 1 annevk 2014-12-06 21:52:15 +0000 I don't understand. Client points to the service worker, no? Did you read the definition of queue a fetch task? 115997 2 jungkees 2014-12-08 02:11:53 +0000 The request's client referred to within FetchEvent.default() is the service worker client not the service worker as the service worker client is the actual request initiator. So I was trying to see the possibility to set the target of the queue a fetch task explicitly a client rather than a request. 116008 3 annevk 2014-12-08 12:51:20 +0000 If client is not the service worker, how does comment 0 make sense? It's not entirely clear to me what kind of setup would work best here :-( 116035 4 jungkees 2014-12-09 02:37:21 +0000 (In reply to Anne from comment #3) > If client is not the service worker, how does comment 0 make sense? > Yeah, right. If we wanted this, it should be defined as "To queue a fetch task on environment settings object _client_ to run an operation, queue a task to run an operation on _client_'s responsible event loop using the networking task source." and I would have to run "To queue a fetch task on the service worker(https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-global-scope-service-worker)'s environment settings object to run an operation, do the steps." in e.default() algorithm. > It's not entirely clear to me what kind of setup would work best here :-( If it doesn't make any side effects, overriding the request's client to service worker's environment settings object in e.default() can be an option as well. But I'm a bit worried about this lest it break any forward compatibility with fetch algorithm. What say you? 117344 5 annevk 2015-01-20 10:01:46 +0000 Say we have a worker A that is controlled by a service worker SW. A invokes fetch() which creates a "fetch" which ends up in SW. If SW then does fetchEvent.default() and that reuses "fetch" from A, how are both parties (A and SW) getting the correct annotated event loop tasks? That seems impossible with the current setup. 117542 6 annevk 2015-01-28 11:35:28 +0000 So the answer here is to remove default() and mark this WONTFIX, no? See https://github.com/slightlyoff/ServiceWorker/issues/607 about replacing default(). 117550 7 jungkees 2015-01-28 11:59:30 +0000 It depends on the conclusion we'll end up. I thought you were opened to find a way to preserve the original (A's) request's setup including request's client (as A's environment settings object) and referrer to keep default(). However, I think e.default() doesn't provide any advantages over fetch(e.request) to authors having considered that Fetch provides Response.finalURL. 119237 8 annevk 2015-04-05 11:53:43 +0000 Yeah, Referer preservation is lost though perhaps we can make Referer settable and save it. We'll see. I don't think anyone wants default() back at this point though and the proposed model in comment 0 is still broken.