HTTP.sys engine never fills RemoteIpAddress (nor RemotePort/LocalPort): rate limiting and forwarded headers silently stop working

[Stemonik]

Summary

On the HTTP.sys engine Request.RemoteIpAddress is always empty, RemotePort is always 0, and LocalPort is always 80 (also on 443). Your own rate limiter and forwarded-headers middleware depend on that address, and both stop doing their job without any error.

Where

Sources/Server/Dext.Server.HttpSys.pas, TDextHttpSysConnection.Init:

FLocalPort := 80;
FRemotePort := 0;
FRemoteAddress := '';

Nothing assigns them afterwards. The data is in the request: HTTP_REQUEST.Address carries pRemoteAddress and pLocalAddress (SOCKADDR, AF_INET or AF_INET6). But Dext.Server.HttpSys.Api declares them as PNetAddr = Pointer; // Placeholder, and nothing reads them.

TDextNativeHttpContext then passes AConnection.RemoteAddress to TDextNativeHttpRequest, so the empty string reaches IHttpRequest.RemoteIpAddress.

Consequences

• Dext.RateLimiting with psIpAddress: every client lands in the same '' partition. One busy client uses up the limit for everybody, and the limit no longer protects against any single client.
• Dext.Web.ForwardedHeaders: IsProxyTrusted('') is never true. Behind a reverse proxy (IIS/ARR, the usual setup in front of HTTP.sys), X-Forwarded-For is therefore always ignored.
• Anything that logs or audits the client address records nothing.

We noticed it through our own login rate limit, which counts per IP. On Indy it works; on HTTP.sys every client counted as the same one.

Suggested fix

In Init, read the two sockaddrs:

• address from sin_addr or sin6_addr, formatted with InetNtopW or RtlIpv4AddressToStringW/RtlIpv6AddressToStringW;
• port from sin_port/sin6_port, converted with ntohs.

It may be cleaner to type HTTP_TRANSPORT_ADDRESS properly in the Api unit first. We are happy to send a PR in whatever shape you prefer.

Checked against f440e79a.

🤖 Generated with Claude Code

[cesarliws]

Thank you for the detailed report and root-cause analysis!

You are completely right: HTTP_TRANSPORT_ADDRESS was left as a placeholder during the initial HTTP.sys implementation, and RemoteIpAddress/ports were hardcoded/unassigned in TDextHttpSysConnection.Init. This is indeed critical for rate-limiting, forwarded headers, and logging.

I would love to receive a PR for this!

Here is our preference for the design:

1. API declarations (Dext.Server.HttpSys.Api.pas):

   • Add Winapi.Winsock2 to uses (under {$IFDEF MSWINDOWS}).
   • Type pRemoteAddress and pLocalAddress as PSOCKADDR (or PSOCKADDR_STORAGE / typed pointer).

2. Parsing (Dext.Server.HttpSys.pas):

   • In TDextHttpSysConnection.Init, handle both AF_INET and AF_INET6 families:
     • Port: Extract using ntohs(PSockAddrIn(P)^.sin_port) / ntohs(PSockAddrIn6(P)^.sin6_port).
     • IP: Convert using InetNtopW (from Winapi.Winsock2) or RtlIpv4AddressToStringW / RtlIpv6AddressToStringW.
   • Extract both pRemoteAddress (for FRemoteAddress / FRemotePort) and pLocalAddress (for FLocalPort).

3. Tests:

   • If possible, include a unit/integration test verifying that TDextHttpSysConnection.Init correctly populates RemoteAddress, RemotePort, and LocalPort from a mocked HTTP_REQUEST.Address structure.

Looking forward to your PR!