2

As of about 2017, it has been possible to abort a fetch and immediately move-on in front-end javascript. I'm having trouble finding any information on what this does to the HTTP connection, though. Does it close it prematurely, or does the browser keep the request open, and just discard the response as it arrives?

I have a use-case where a user is making a (potentially) expensive database calls from a webapp frontend. Sometimes, they notice that a request is taking too long, and manually cancel it. I would love to be able to take that signal and cancel my expensive database query, since they're no longer interested in the results.

Is there any way that my REST server can tell that the fetch has been aborted? (My server is a Java Jersey/Grizzly.)

Andrew Rueckert
  • 4,858
  • 1
  • 33
  • 44
  • 1
    It aborts the request, it may close the connection or stream (in case of HTTP/2). Whether or not you can react to this depends on your backend framework/language/libraries and perhaps proxies. – Evert Aug 03 '21 at 18:43
  • 1
    Which tech is your REST server ? In Node for example you can listen for `close` and/or `aborted` events – Gabriele Petrioli Aug 03 '21 at 18:45
  • @GabrielePetrioli updated my question with my server stack. – Andrew Rueckert Aug 03 '21 at 18:48
  • 1
    @AndrewRueckert I would also add tags for that tech, and what you tried so far. I know nothing about this tech stack, so cant' really help you further.. but this is a techstack-specific question, not a general one =) – Evert Aug 03 '21 at 18:52
  • Perhaps https://stackoverflow.com/questions/26752880/clientabortexception-when-using-jersey-2-13/39006980#39006980 would be useful to you. – Gabriele Petrioli Aug 03 '21 at 19:58

1 Answers1

4

It's generally supposed to:

https://fetch.spec.whatwg.org/#http-network-fetch step 17.2.3/4

  1. If aborted, then:

    1. If fetchParams is aborted, then:

      1. Set response’s aborted flag.

      2. If stream is readable, then error stream with the result of deserialize a serialized abort reason given fetchParams’s controller’s serialized abort reason and an implementation-defined realm.

    2. Otherwise, if stream is readable, error stream with a TypeError.

    3. If connection uses HTTP/2, then transmit an RST_STREAM frame.

    4. Otherwise, the user agent should close connection unless it would be bad for performance to do so.

      For instance, the user agent could keep the connection open if it knows there’s only a few bytes of transfer remaining on a reusable connection. In this case it could be worse to close the connection and go through the handshake process again for the next fetch.

However, Firefox currently might not in some cases (https://bugzilla.mozilla.org/show_bug.cgi?id=1568422).

ZachB
  • 13,051
  • 4
  • 61
  • 89