redb.Route.Http.Hosting 4.0.0

redb.Route.Http.Hosting

Shared Kestrel HTTP hosting infrastructure for the redb.Route ESB framework.

Provides SharedHttpServerManager — a multiplexing HTTP server (one Kestrel per host:port, many routes) used by HTTP-based transports (redb.Route.Http, redb.Route.As2, …). Extracting it here lets those connectors share one server manager without depending on each other: register it once with services.AddRedbRouteHttpHosting() (idempotent), and every connector resolves the same singleton — so an HTTP route and an AS2 route in the same worker share one Kestrel and never fight over a port.

Standalone hosting only — depends on the ASP.NET runtime, not on redb.Route core or any connector.

TLS: asking for it selects the socket

A listener registered with ssl: true resolves its server certificate from, in order:

1. the endpoint — sslCertPath / sslCertPassword on the route URI;
2. a named connection factory, so the password stays out of the URI;
3. the host default set here.

services.AddRedbRouteHttpHosting(o => o.Tls.DefaultCertificatePath = "/certs/server.pfx");
// or an already-loaded certificate:
services.AddRedbRouteHttpHosting(o => o.Tls.DefaultCertificate = cert);

This is the shape Camel gives global SSLContextParameters and Spring Boot gives SSL bundles: a certificate on the endpoint is an override, not a requirement. Nothing here turns TLS on — ssl stays an explicit per-endpoint decision; the host only answers "with which certificate".

A listener that asks for TLS and finds no certificate anywhere refuses to bind. It does not fall back to a plaintext socket, which is what nginx, httpd, Jetty, Spring Boot and Kestrel's own UseHttps() all do, and for the same reason: an open port behind an https:// banner is not "TLS off", it is a silent downgrade that operators cannot see.

Trusted proxies

Behind a reverse proxy the socket peer is the proxy, and the client's address and scheme travel in X-Forwarded-For / X-Forwarded-Proto. Which proxies to believe is a property of the process, so it is set once on the host and applies to every listener and every consumer on it:

services.AddRedbRouteHttpHosting(o => o.TrustedProxies.Add("10.0.0.5").Add("10.1.0.0/16"));
// or, constructing the manager by hand:
var hosting = new HttpHostingOptions();
hosting.TrustedProxies.Add("10.0.0.5");
var manager = new SharedHttpServerManager(hosting);

Rules, in the order they apply:

The originals are kept in HttpContext.Items under SharedHttpServerManager.OriginalRemoteAddressItem and OriginalSchemeItem. Keep the list to the proxies you operate: a network an attacker can send from lets them choose their own client address. X-Forwarded-Host and the RFC 7239 Forwarded header are not handled.

The walk is ForwardedHeaderResolver, a pure function with no HttpContext in it, so it can be unit-tested on strings and reused by a host that is not Kestrel.

Part of the redb.Route family.