Suave 3.7.1

• net10.0

  • FSharp.Core (>= 10.0.102)

Security: a client that opened a connection to an HTTPS binding and never completed the TLS handshake stopped that binding from accepting anyone else (with the default `acceptorCount = 1`, one idle TCP connection made the HTTPS site unreachable until it closed). The handshake now runs on the connection's own task instead of the accept loop, and is bounded by the new process-wide `Tcp.tlsHandshakeTimeout` (default 10 seconds; set it before starting the server). A connection whose handshake fails or times out now has its socket closed; previously the socket was left open
`Proxy.proxy` forwards requests faithfully: the target is built from `rawPath` and `rawQuery` (it used the decoded `path` and dropped the query, so `/a/b%2Fc?x=1` arrived as `/a/b/c`), and a path on the upstream URI is kept as a prefix (`proxy (Uri "http://backend/api")` maps `/users` to `/api/users`). A request path with a `.` or `..` segment (also percent-encoded) is answered with 400 instead of being able to leave that prefix
`Proxy.proxy` forwards every request header except hop-by-hop ones (RFC 9110 §7.6.1: `Connection`, `Keep-Alive`, `Proxy-Connection`, `TE`, `Trailer`, `Transfer-Encoding`, `Upgrade`, `Proxy-Authorization`, `Proxy-Authenticate` and any named in `Connection`), `Host`, `Content-Length` and `Expect`; it used to forward only `User-Agent`, `Accept`, `Date`, `Content-Type` and `Content-Length`, so `Authorization`, `Cookie`, API keys and the like were lost. The request body is forwarded whenever there is one (it was only forwarded for POST and PUT, so PATCH and DELETE lost theirs). `multipart/form-data` bodies are parsed by Suave before any WebPart runs and still cannot be forwarded
`Proxy.proxy` passes any upstream status through with its reason phrase; statuses Suave has no `HttpCode` for (e.g. 207, 418) used to become 502 while the upstream body was still sent. Response headers are forwarded without hop-by-hop headers and without `Date`/`Server` (Suave writes its own), and repeated headers such as `Set-Cookie` are kept as separate headers instead of being joined with commas
Behaviour change:** `Proxy.proxy` no longer trusts `X-Forwarded-For`, `X-Forwarded-Proto`, `X-Forwarded-Host`, `Forwarded` or `X-Real-IP` sent by the client: `X-Forwarded-For` is the connection's address, `-Proto` and `-Host` are the scheme and `Host` the proxy received, and `Forwarded`/`X-Real-IP` are dropped. A client could send `X-Forwarded-Proto: https` over plain HTTP, or any address in `X-Forwarded-For`, and have it passed on. Behind another reverse proxy, list its address in `ProxyOptions.trustedProxies` to keep its headers and extend its `X-Forwarded-For` chain
Security: the `HttpClient` shared by all proxies no longer keeps a cookie container. Upstream `Set-Cookie` responses were stored in it and sent with later proxied requests from every client
Add `Proxy.proxyWith options upstream` and `Proxy.defaultProxyOptions` (`timeout`, `trustedProxies`, `dropRequestHeaders`, `onError`). The proxy answers 504 when the upstream has not sent its response headers within the timeout (30 seconds by default; there was none) and 502 when it cannot be reached; `onError` is called with the exception first. `proxy` and `proxyWith` throw `ArgumentException` straight away for an upstream that is not an absolute http/https URI