Request Cancellation

[pjebs]

With net/http server, when the client cancels the request, the context attached to the request object returns a done signal which you can use to cancel processing the rest of the request.

We are not talking about fixed duration timeouts here.

Why does fasthttp not support request cancelation?

via Fiber framework:

func Handler(c *fiber.Ctx) error {
	ctx := c.Context()
	<-ctx.Done()
}

[kirillDanshin]

hey @pjebs. fiber's c.Context() returns *fasthttp.RequestCtx. your example uses fasthttp's (*RequestCtx).Done(). please clarify what your question is.

[pjebs]

In standard net/http:

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    <-ctx.Done()
}

Function returns only if the client cancels the request.
In a more practical example, it allows our handler to detect if the client has cancelled the request, and hence is no longer waiting for a response. Therefore we can just cancel any operations we were doing to produce a response.

This is independent of a timeout.

With fasthttp, it does not seem to be able to detect when the client has cancelled the request.

(NB: I am using fasthttp via fiber framework, hence ctx := c.Context())

I was told my Fiber that this issue is fasthttp related and not fiber related.

[erikdubbelboer]

I'm afraid that this is not possible. With fasthttp we read the full request and body before calling your handler, and we only write the response after your handler returns. In between nothing happens to the connection so it's impossible to know if the client closed the connection. You can only know if a connection is closed by doing an operation on it.

net/http also only closes ctx.Done() if you try to write something to the response or if you try to read the request body. If you don't do anything it won't notice either. See #771

And because fasthttp doesn't do any operations on the socket while your handler is running this is impossible for us to implement.

[andersryanc]

net/http also only closes ctx.Done() if you try to write something to the response or if you try to read the request body. If you don't do anything it won't notice either. See #771

I was just testing this using the following simple net/http handler and it works as expected. I don't have to try to write to the response or read the body... the "END - done" text shows up in my console immediately when I cancel the request in postman AND execution stops (ie. "responded: OK" does not appear in the console at the end of the timeout).

package main

import (
  "fmt"
  "net/http"
  "time"
)

func main() {
  http.ListenAndServe(":5100", test())
}

func test() http.HandlerFunc {
  return func(w http.ResponseWriter, r *http.Request) {
    select {
    case <-time.After(3 * time.Second):
      // continue

    case <-r.Context().Done():
      fmt.Println("END - done")
      return
    }

    fmt.Println("responded: OK")
    w.Write([]byte("OK"))
  }
}

NOTE: I tested this using docker going all the way back to go 1.11 and it worked in all cases.

docker run -v `pwd`:/app -p 5100:5100 -it golang:1.11 bash
$ cd /app && go run .

# ... golang:1.12 bash
# ... golang:1.13 bash

docker run -v `pwd`:/app -p 5100:5100 -it golang:1.18 bash
$ cd /app && go run .

And when using the same simple handler in fasthttp, it does not work:

package main

import (
  "fmt"
  "time"

  "github.com/valyala/fasthttp"
)

func main() {
  fasthttp.ListenAndServe(":5100", test)
}

func test(ctx *fasthttp.RequestCtx) {
  select {
  case <-time.After(3 * time.Second):
    // continue

  case <-ctx.Done():
    fmt.Println("END - done")
    return
  }

  fmt.Println("responded: OK")
  ctx.WriteString("OK")
}

Same thing with fiber (obviously, since it uses fasthttp under the hood):

package main

import (
  "fmt"
  "log"
  "time"

  "github.com/gofiber/fiber/v2"
)

func main() {
  app := fiber.New()
  app.Get("/test", test)
  log.Fatal(app.Listen(":5100"))
}

func test(c *fiber.Ctx) error {
  select {
  case <-time.After(3 * time.Second):
    // continue

  case <-c.Context().Done():
    fmt.Println("END - done")
    return nil
  }

  fmt.Println("responded: OK")
  return c.SendString("OK")
}

I'm facing a similar issue in my application where I have a long running process in the background which I would like to be able to cancel should the connection get closed or the request aborted by the user. Is there nothing that can be done to solve this in fasthttp?

And because fasthttp doesn't do any operations on the socket while your handler is running this is impossible for us to implement.

Is net/http listening to the socket and that is why it's able to accomplish the correct behavior? Is there a specific reason why fasthttp doesn't continue to listen for the socket being closed? Would that lead to a drop in overall performance or something?

[sn0rk64]

Any solutions?

[a5r0n]

It's not going to change any time soon, fasthttp is built with performance as the number one property, as so, they have to make some choices and one of them is to hold the context as short as they can.

If you really need that, use other frameworks like gin.