Handing fetch termination #1178

jakearchibald · 2017-08-07T09:02:29Z

Is this a valid way of handling this, in terms of whatwg/fetch#523.

It seems too easy.

(I'll add the same to foreign fetch if this is 👍 )

annevk · 2017-08-07T10:01:40Z

docs/index.bs

@@ -2996,6 +2997,9 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe
              1. If |e|'s [=FetchEvent/respond-with error flag=] is set, set |handleFetchFailed| to true.
              1. Else, set |response| to |e|'s [=FetchEvent/potential response=].
          1. If |e|'s <a>canceled flag</a> is set, set |eventCanceled| to true.
+          1. Run the following steps [=in parallel=]:
+              1. Wait for the fetch to become [=fetch/terminated=].
+              1. [=Queue a task=] to [=AbortSignal/signal abort=] on |requestObject|'s [=Request/signal=].


It seems this algorithm has a chance to never finish.

Yeah, I figured "GC" would take care of it.

What's the alternative? "Wait for the fetch to become [=fetch/terminated=], or (something that signal successful completion)"

I tried to think about this a bit and the way XMLHttpRequest seems to approach is that you always get a response from the fetch process, but it might be a network error annotated with a termination reason. And for the request/response bodies we got the stream that errors.

I could wait until on of the following:

Fetch is terminated.

"Process response" for fetch occurs, and the response type is "error".

"Process response done" for fetch occurs.

Then, only signal abort if fetch is terminated.

What I was saying is that currently "Fetch is terminated." is not really a signal we expose to the outside (other than the response having a termination reason or the stream erroring).

This makes the following changes: * Integrates DOM's `AbortSignal`. * Specifies abort points and how to handle termination. * Replaces termination reason with an aborted flag. Tests: web-platform-tests/wpt#6484. Service worker integration follow-up: w3c/ServiceWorker#1178. Fixes #447. Closes #563.

jakearchibald · 2017-09-28T12:44:42Z

@annevk re:

"Fetch is terminated." is not really a signal we expose to the outside (other than the response having a termination reason or the stream erroring).

I agree, but this feels like a special case since fetch called me, I didn't call fetch.

In the fetch spec I've tried to keep termination handling as close to the leaf end as I can. HTTP fetch doesn't have a "If terminates" break clause around the call to service workers, so it feels "handle fetch" should be handling the termination.

Alternatively, I could add a break clause the call to "handle fetch" in "main fetch". Then, in "handle fetch" I can somehow "handle response" for the outer fetch, and see if its abort flag is set. But this will be really messy, as the fetch spec is waiting for a response from the service worker spec, but the service worker spec is also waiting for a response from the fetch spec. I'd also end up looping the service worker response back into the service worker spec via the fetch spec, and I'd need to ignore that somehow.

I've updated the PR a little, but it seems to express the behaviour pretty clearly. It's a bit hand-wavey around getting an instance of the fetch, but I think that's part of whatwg/fetch#536 (comment).

annevk · 2017-09-28T13:06:33Z

docs/index.bs

          1. Initialize |e|’s {{Event/type}} attribute to {{fetch!!event}}.
          1. Initialize |e|’s {{Event/cancelable}} attribute to true.
-          1. Initialize |e|’s {{FetchEvent/request}} attribute to a new {{Request}} object associated with |request| and a new associated {{Headers}} object whose [=guard=] is "`immutable`".
+          1. Initialize |e|’s {{FetchEvent/request}} attribute to |requestObject|


Needs a trailing dot.

annevk · 2017-09-28T13:08:11Z

Yeah, I guess we need to fix that issue at some point. Not looking forward to updating all the callers again.

jakearchibald · 2017-09-28T15:32:45Z

@annevk Are you ok with:

Let |fetchInstance| be the instance of the [=/fetch=] algorithm representing the ongoing fetch.

And

If |fetchInstance| is [=fetch/terminated=], then…

Here?

If so I'll write some tests and get this merged.

annevk · 2017-09-28T18:02:51Z

Yeah, as you said there's not really any better way to do it at the moment. Maybe note these cases in the Fetch issue so we make sure they get addressed by whatever we come up with?

jakearchibald · 2017-10-11T13:19:28Z

Tests at web-platform-tests/wpt#7674

jungkees

I defer to @annevk's review for this.

jungkees · 2017-11-16T05:35:16Z

@jakearchibald, it seems this is ready to be merged?

jakearchibald · 2017-11-16T10:21:58Z

Done. I need to take another pass at the tests. Just minor stuff though.

ItalyPaleAle · 2020-10-07T03:09:21Z

Hi all, sorry for resurrecting this old thread. Wondering if this behavior that I'm noticing is the one as intended according to the spec, as I'm noticing the same thing on all major browsers (Firefox, Chromium, Safari).

It seems that this doesn't catch situations where the browser itself is terminating a request.

Example:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Test fetch</title>
</head>
<body>

<button onclick="getVideo()">Get video</button>
<button onclick="stop()">Stop</button>
<div id="out"></div>

<script>
;(async function() {
    await navigator.serviceWorker.register('sw.js')
    console.info('Service worker registered')
    await navigator.serviceWorker.ready
    console.log('Service worker installed')
    document.getElementById('out').innerText = 'Ready'
})()

function getVideo() {
    document.getElementById('out').innerHTML = '<video autoplay controls  muted="muted" src="video.mp4" style="width: 400px; height: auto;"></video>'
}

function stop() {
    document.getElementById('out').innerHTML = ''
}
</script>

</body>
</html>

sw.js

self.addEventListener('install', () => {
    self.skipWaiting()
})

self.addEventListener('fetch', (event) => {
    console.log('fetch', event)
    event.request.signal.addEventListener('abort', (event) => {
        console.log('aborted', event)
    })
})

self.addEventListener('activate', () => self.clients.claim())

Description

Place a video file in the same folder called video.mp4, ideally a large-r file (say, 100MB+). Start a server (e.g. docker run --rm --name some-nginx -v $PWD:/usr/share/nginx/html:ro -p 8080:80 nginx) and navigate to the page (http://localhost:8080).

Start playing the video (hint: it helps to throttle the network), then press the "stop" button before the video is done loading. Alternatively, skip forward in the video to a part that hasn't been buffered yet.

In the dev tools, you'll see the browser interrupted the old request (and made a new one if necessary).

However, the abort event is never triggered. And, in the console, even after the request is done, the signal objected nested into event still reports the request as not aborted.

Is this how it's supposed to behave according to specs? Or is it a bug in the browsers?

Why am I doing this? I have a SW that intercepts a request and makes a new one instead. I need to be able to understand if the browser has canceled the "original" request to cancel the new one too.

wanderview · 2020-10-07T15:37:11Z

I recently raised the same issue on #1544.

I think the intent was to abort the signal here, but no browser implements it yet. Also, as I mention in the issue above there may be a spec problem that also makes it not do what is intended.

ItalyPaleAle · 2020-10-07T15:57:13Z

Thanks, @wanderview ! I'll follow the other thread then. If you need more details on what I'm trying to do, to add to your case on #1544, please let me know.

jakearchibald requested review from jungkees and annevk August 7, 2017 09:02

annevk reviewed Aug 7, 2017

View reviewed changes

annevk mentioned this pull request Sep 20, 2017

Aborting fetch whatwg/fetch#523

Merged

jakearchibald added 2 commits September 28, 2017 13:04

Handing fetch termination

a00a8ca

Catering for navigation preloads

d4fd56b

jakearchibald force-pushed the fetch-abort branch from 2358afd to d4fd56b Compare September 28, 2017 12:34

jakearchibald changed the title ~~WIP: Handing fetch termination~~ Handing fetch termination Sep 28, 2017

annevk reviewed Sep 28, 2017

View reviewed changes

Missing dot

b035492

jakearchibald mentioned this pull request Oct 11, 2017

Service worker fetch abort tests web-platform-tests/wpt#7674

Open

jungkees approved these changes Oct 16, 2017

View reviewed changes

jakearchibald merged commit 5474d11 into master Nov 16, 2017

annevk deleted the fetch-abort branch November 16, 2017 15:41

annevk mentioned this pull request Nov 2, 2021

Add abort reason to abort fetch whatwg/fetch#1343

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handing fetch termination #1178

Handing fetch termination #1178

jakearchibald commented Aug 7, 2017 •

edited by pr-preview bot

Loading

annevk Aug 7, 2017

jakearchibald Aug 7, 2017

annevk Aug 7, 2017

jakearchibald Aug 7, 2017

annevk Aug 7, 2017

jakearchibald commented Sep 28, 2017 •

edited

Loading

annevk Sep 28, 2017

annevk commented Sep 28, 2017

jakearchibald commented Sep 28, 2017

annevk commented Sep 28, 2017

jakearchibald commented Oct 11, 2017

jungkees left a comment

jungkees commented Nov 16, 2017

jakearchibald commented Nov 16, 2017

ItalyPaleAle commented Oct 7, 2020

wanderview commented Oct 7, 2020

ItalyPaleAle commented Oct 7, 2020

Handing fetch termination #1178

Handing fetch termination #1178

Conversation

jakearchibald commented Aug 7, 2017 • edited by pr-preview bot Loading

annevk Aug 7, 2017

Choose a reason for hiding this comment

jakearchibald Aug 7, 2017

Choose a reason for hiding this comment

annevk Aug 7, 2017

Choose a reason for hiding this comment

jakearchibald Aug 7, 2017

Choose a reason for hiding this comment

annevk Aug 7, 2017

Choose a reason for hiding this comment

jakearchibald commented Sep 28, 2017 • edited Loading

annevk Sep 28, 2017

Choose a reason for hiding this comment

annevk commented Sep 28, 2017

jakearchibald commented Sep 28, 2017

annevk commented Sep 28, 2017

jakearchibald commented Oct 11, 2017

jungkees left a comment

Choose a reason for hiding this comment

jungkees commented Nov 16, 2017

jakearchibald commented Nov 16, 2017

ItalyPaleAle commented Oct 7, 2020

index.html

sw.js

Description

wanderview commented Oct 7, 2020

ItalyPaleAle commented Oct 7, 2020

jakearchibald commented Aug 7, 2017 •

edited by pr-preview bot

Loading

jakearchibald commented Sep 28, 2017 •

edited

Loading