if you use write that returns a Future and call close when Future isDone

I can still reproduce the problem when using a blocking Future

withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
  channel.write(ByteBuffer.wrap(data)).get()
  channel.close()
}

net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

There must be a better way to do

close()

that won't cut off the stream while the browser is reading

Look at a CompletionHandler

there's a completion handler in my StackOverflow example, putting close inside the completion handler still causes

net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

When you're done writing and the completion handler is called, it doesn't actually mean that the browser received your written data, just that the kernel received your data and calling close() too soon wipes the buffer before the browser can read it

Apologies I didn't look at the stackoverflow link. What is the client side doing?

client side is literally just displaying the GET request, at least that's what I've simplified it down to

Have you had a look at Netty or Jetty code?

I've had a look at a few frameworks so far and all of them are just using Netty, Netty itself is enormous, so I haven't gotten my head around the closing mechanism yet. I'll definitely check out Jetty too, thanks for the hint!

I do have a content-length header

headers.add("Content-Length: ${body.length}")

without closing the connection, window.fetch for GET / POST from JavaScript just hangs like this indefinitely

What is happening in the network tab? Or even when looking at the session with wireshark? With HTTP 1.1 the client should send a close request. Are you handling those?

in the network tab, the first 6 requests are going through, then anything after that just hangs since the first 6 requests aren't considered done

Is there a Connection header in request?

there was one, I've removed it earlier in my trying things out, let me put that back

Seems like the absence implies persistent. You should check for presence and if it has

close

then close the socket otherwise leave the socket open.

seems like AWS is rewriting the Connection param let me tinker with the load balancer settings

Try TCP load balancer.

I'm going to remove Connection: close from my side and then implement persistent connections I noticed that the browser is sending more data over the same connection, so once I've handled the first request on a connection, and written a response, I need to read again indefinitely until the connection dies This is how the postgresql protocol works as well, write, read, write read, write, read, just in the reverse for http1.1