Runtime limits

PassBeyond currently uses fixed HTTP and metadata limits. They are not configurable through YAML or environment variables.

Incoming HTTP server

Limit	Value	Scope
Request read timeout	10 seconds	Headers and request body read by PassBeyond
Header read timeout	10 seconds	Time allowed to read request headers
Response write timeout	30 seconds	Time allowed while writing a response
Maximum request headers	1 MiB	Aggregate incoming HTTP headers

These values affect proxied application traffic as well as PassBeyond endpoints. Increasing an nginx, Apache, or load-balancer timeout does not extend the internal PassBeyond timeout.

Workload implications

• Slow or large uploads can exceed the 10-second read timeout.
• Long-running backend responses can exceed the 30-second write timeout.
• Server-Sent Events and other indefinite streams are not a suitable documented workload.
• WebSocket upgrades are supported by Go's reverse proxy, but long-lived behavior is not guaranteed by a configurable PassBeyond timeout policy.
• Large cookies or forwarded application headers count toward the request-header limit.

Test representative upload sizes, response durations, and upgraded connections before placing an application in production.

Backend transport

Limit	Value
Idle backend connection timeout	90 seconds
Backend TLS handshake timeout	10 seconds
100-continue wait	3 seconds

PassBeyond does not impose a separate configured backend response-body size. The public response is still subject to the 30-second server write timeout.

IdP metadata

Limit	Value
Remote metadata request timeout	30 seconds
Remote metadata bytes read	10 MiB
Automatic refresh interval	30 minutes

Only HTTP status 200 is accepted. A response larger than the read limit is truncated and normally fails XML parsing. Local metadata files do not use the remote request timeout or refresh interval.

Session and cookie size

PassBeyond stores the subject and every mapped SAML attribute in the signed JWT cookie. It does not define a smaller application-level JWT limit, but browsers and edge proxies commonly impose much lower cookie and header limits than PassBeyond's 1 MiB maximum.

Large group membership is the most common risk. Symptoms can include:

• the browser silently refusing the session cookie;
• 400 or 431 at an edge proxy;
• an immediate login loop after a valid SAML response;
• backend identity headers exceeding downstream limits.

Configure the IdP to send only attributes and groups required by the protected application. Do not use the JWT as a general-purpose directory profile.

Attribute serialization

Single-valued attributes become one HTTP header value. Groups are joined with commas and are not escaped individually. A group name that itself contains a comma is therefore ambiguous to the backend.

Header names are derived from normalized claim keys. HTTP header names are case-insensitive, and intermediaries may display their capitalization differently.

Capacity controls not provided

PassBeyond currently has no built-in:

• rate limiter;
• connection or concurrency limit;
• request-body size setting;
• metrics endpoint;
• dedicated health/readiness endpoint;
• configurable graceful-drain period.

Apply request-size, rate, connection, and abuse controls at the public TLS proxy. Process supervision and external end-to-end checks remain necessary.

See Troubleshooting and Known limitations.