Idea: Give option to implement context.Context properly

[pjebs]

Currently fasthttp.RequestCtx implements context.Context nominally.
For performance reasons: Done() and Err() are essentially nop (With exception that if Server shuts down, channel will get closed).

In #965 (comment), @erikdubbelboer mentions that in between the time of reading the request from the connection and writing to the response (after Handler returns), nothing is done to the connection, hence we can not know when the client has closed the connection.

You incorrectly state that net/http works the same way.

In the browser, it is not uncommon to call a search endpoint when a user types text into a searchbox. As the user keeps typing text, it is not uncommon to cancel the prior request and fire another request to the search endpoint: https://developer.mozilla.org/en-US/docs/Web/API/AbortController

I think fasthttp can implement a setting in RequestCtx that can be activated for a given endpoint only (eg search endpoint), that when activated, behind the scenes does a poll of the connection.

It checks at regular small time intervals by attempting to read from the connection. If the read fails, we know the connection was closed, and the done signal can be sent. (OR even more radical, we depart from context.Context guidelines and we set the Err() to non-nil and ignore adding a done channel)

We also document what is happening behind the scenes and explain that there will be a slight performance hit. It is opt-in.

[erikdubbelboer]

It might sound easy but implementing this won't be, especially not in a performant way. You'll have to manage an extra pool of goroutines for this. And any bytes you read you'll have to buffer for the next request somehow.

I would be open to a pull request, I don't have time to implement something like this myself.

[pjebs]

In a normal HTTP Request (that you would enable this "mode"), after the browser makes a request, is it safe to assume that there will be no more data to read from the connection? (i.e. it's not bidirectional like a websocket, and the developer only enables it for an endpoint it knows browser won't be sending more data).

Therefore the client is just waiting for a response only. That means an attempt to read is simply to check if the client closed connection.

Is there a technical misunderstanding in my knowledge?

[erikdubbelboer]

Is this for sending or receiving requests? You talk about RequestCtx which is only used in the server when receiving requests.

[pjebs]

Fasthttp Server receiving a request from browser.
Endpoint handler being able to detect when browser aborts request using JS AbortController similar to net/http functionality with context cancellation.

[erikdubbelboer]

Clients can send multiple requests before receiving a response. It's called http pipelining and it's an important feature fasthttp supports.

[pjebs]

Is there any acceptable way you can think of to make request abortion detectable?

[erikdubbelboer]

I think reading from the connection like you said should be possible. But there are a bunch of edge cases like pipelining and timeouts that need to be handled in the code.

[pjebs]

Do you think the goroutines I use to poll the connection should be kept in a pool?

Also, when we implemented the Early Hints, at the start of the handler (after reading request), we grabbed the connection and wrote to it. How was that not effected by pipelining?

[erikdubbelboer]

Yes, to reduce allocations etc the goroutines should definitely be kept in a pool and be reused.

Because with pipelining you still send the responses in the same order. So the browser will still see the Early Hints response for the correct request.

[pjebs]

@erikdubbelboer How do I go about keeping go routines in a pool?

[erikdubbelboer]

@pjebs you can look at how https://github.com/valyala/fasthttp/blob/master/workerpool.go does it.