Close the underlying tcp connection when rejecting

[shterrett]

When using this library in conjunction with servant-websockets, we noticed that after rejecting the request, the connection was held open until it timed out, approximately one minute later. Our current workaround is to accept the connect and then immediately sendClose and exit.

This adds rejectAndCloseWith to reject the request and close the underlying tcp connection immediately to avoid the workaround above.

[shterrett]

The build failure appears to be an issue with CircleCI fetching the stack lts

#!/bin/bash -eo pipefail
stack --no-terminal --copy-bins test --pedantic

Downloading lts-15.6 build plan ...
RedownloadInvalidResponse Request {
  host                 = "raw.githubusercontent.com"
  port                 = 443
  secure               = True
  requestHeaders       = []
  path                 = "/fpco/lts-haskell/master//lts-15.6.yaml"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}
 "/root/.stack/build-plan/lts-15.6.yaml" (Response {responseStatus = Status {statusCode = 404, statusMessage = "Not Found"}, responseVersion = HTTP/1.1, responseHeaders = [("Connection","keep-alive"),("Content-Length","14"),("Content-Security-Policy","default-src 'none'; style-src 'unsafe-inline'; sandbox"),("Strict-Transport-Security","max-age=31536000"),("X-Content-Type-Options","nosniff"),("X-Frame-Options","deny"),("X-XSS-Protection","1; mode=block"),("Content-Type","text/plain; charset=utf-8"),("Via","1.1 varnish (Varnish/6.0), 1.1 varnish"),("X-GitHub-Request-Id","E114:768A:F93F50:11C1623:5FA98AF4"),("Accept-Ranges","bytes"),("Date","Mon, 09 Nov 2020 18:31:17 GMT"),("X-Served-By","cache-wdc5554-WDC"),("X-Cache","MISS, MISS"),("X-Cache-Hits","0, 0"),("X-Timer","S1604946677.248789,VS0,VE137"),("Vary","Authorization,Accept-Encoding"),("Access-Control-Allow-Origin","*"),("X-Fastly-Request-ID","07d6d8c7a70261ff968d1cb3729faf52197f1876"),("Expires","Mon, 09 Nov 2020 18:36:17 GMT"),("Source-Age","0")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose})

Exited with code exit status 1

CircleCI received exit code 1

[domenkozar]

Is there any reason why rejectRequest wouldn't close the connection?

[domenkozar]

@shterrett if you rebase on top of master CI failures would go away.

[domenkozar]

I've added a doc note for now ae2aa5e#diff-125df5360210799a9fd1726d6f83c2bdf9388cbbdeeaabd7bf34bf3d1ba94cabR244

[jaspervdj]

Is there any reason why rejectRequest wouldn't close the connection?

Historically, I was assuming it would be the task of the framework (WAI/Snap/...) to close the connection once the WebSockets application finishes. I wanted to avoid double closes, but it maybe depends on the specific framework on whether or not that is a bad thing or the second close would just do nothing.

But ever since we have the Streams abstraction, I guess it's fine to close that it in either case.