Struct Server 

pub struct Server<App> { /* private fields */ }

Serve an app over HTTP.

Implementations

impl<App> Server<App>

where App: Send + Sync + 'static,

pub fn new(router: Router<App>, app: App) -> Self

Create a new server for router and app.

pub fn keep_alive(self, keep_alive: bool) -> Self

Enables or disables HTTP/1.1 persistent connections.

When enabled, the server will allow clients to reuse a TCP connection for multiple requests. Disabling keep-alive forces the connection to be closed after each response is sent.

Disabling keep-alive may reduce resource retention from idle clients but can increase connection overhead due to additional TCP and TLS handshakes.

Default: true

pub fn max_buf_size(self, max_buf_size: usize) -> Self

Sets the maximum size of the HTTP/1.1 connection read buffer.

This buffer is used when reading and parsing the HTTP request line and headers from the client. It does not limit the size of the request body. Use Server::max_request_size to limit the maximum allowed request body size.

Default: 16 KB

pub fn max_connections(self, max_connections: usize) -> Self

Sets the maximum number of concurrent connections that the server can accept.

An idle Via application uses 10 file descriptors on POSIX platforms.

Rather than making you do math for no reason, we subtract 10 from the provided connection budget.

Default: 1024

pub fn reserve_file_descriptors(self, len: usize) -> Self

Reserve the exact number of file descriptors used in your application.

Determinism is the backbone of high assurance.

If you know the exact number of resources your application uses, set this value to ensure the exact amount of backpressure is applied in accept.

Panics

Panics if len is >= to the maximum number of connections.

pub fn max_request_size(self, max_request_size: usize) -> Self

Set the maximum request body size in bytes.

Default: 100 MB

pub fn shutdown_timeout(self, duration: Duration) -> Self

Sets the amount of time that the server will wait for inflight connections to complete before shutting down.

Default: 10s Max: 30s

pub fn http1_header_read_timeout(self, duration: Duration) -> Self

If a client does not transmit the entire request head within this time, the connection is closed.

Default: 10s Max: 30s

pub async fn listen( self, address: impl ToSocketAddrs, ) -> Result<ExitCode, Error>

Listens for incoming connections at the provided address.

Returns a future that resolves with a result containing an ExitCode when shutdown is requested.

Errors

• If the server fails to bind to the provided address.

Exit Codes

An ExitCode::SUCCESS can be viewed as a confirmation that every request was served before exiting the accept loop.

An ExitCode::FAILURE is an indicator that an unrecoverable error occured which requires that the server be restarted in order to function as intended.

If you are running your Via application as a daemon with a process supervisor such as upstart or systemd, you can use the exit code to determine whether or not the process should restart.

If you are running your Via application in a cluster behind a load balancer you can use the exit code to properly configure node replacement and / or decommissioning logic.

When high availability is mission-critical, and you are scaling your Via application both horizontally and vertically using a combination of the aforementioned deployment strategies, we recommend configuring a temporal threshold for the number of restarts caused by an ExitCode::FAILURE. If the threshold is exceeded the cluster should immutably replace the node and the process supervisor should not make further attempts to restart the process.

This approach significantly reduces the impact of environmental entropy on your application’s availability while preventing conflicts between the process supervisor of an individual node and the replacement and decommissioning logic of the cluster.