rama::http::core::server::conn::http1

Struct Builder

pub struct Builder { /* private fields */ }

Available on crate features http-backend and http and std only.

Expand description

A configuration builder for HTTP/1 server connections.

Note: The default values of options are not considered stable. They are subject to change at any time.

§Example

let mut http = Builder::new();
// Set options one at a time
http.set_half_close(false);

// Or, chain multiple options
http.set_keep_alive(false).set_title_case_headers(true).try_set_max_buf_size(8192).unwrap();

Use Builder::serve_connection to bind the built connection to a service.

Implementations§

§

impl Builder

pub fn new() -> Builder

Create a new connection builder.

pub fn with_half_close(self, val: bool) -> Builder

Set whether HTTP/1 connections should support half-closures.

Clients can chose to shutdown their write-side while waiting for the server to respond. Setting this to true will prevent closing the connection immediately if read detects an EOF in the middle of a request.

Default is false.

pub fn set_half_close(&mut self, val: bool) -> &mut Builder

Set whether HTTP/1 connections should support half-closures.

Clients can chose to shutdown their write-side while waiting for the server to respond. Setting this to true will prevent closing the connection immediately if read detects an EOF in the middle of a request.

Default is false.

pub fn with_keep_alive(self, val: bool) -> Builder

Enables or disables HTTP/1 keep-alive.

Default is true.

pub fn set_keep_alive(&mut self, val: bool) -> &mut Builder

Enables or disables HTTP/1 keep-alive.

Default is true.

pub fn with_title_case_headers(self, enabled: bool) -> Builder

Set whether HTTP/1 connections will write header names as title case at the socket level.

Default is false.

pub fn set_title_case_headers(&mut self, enabled: bool) -> &mut Builder

Set whether HTTP/1 connections will write header names as title case at the socket level.

Default is false.

pub fn with_allow_multiple_spaces_in_request_line_delimiters( self, enabled: bool, ) -> Builder

Set whether multiple spaces are allowed as delimiters in request lines.

Default is false.

pub fn set_allow_multiple_spaces_in_request_line_delimiters( &mut self, enabled: bool, ) -> &mut Builder

Set whether multiple spaces are allowed as delimiters in request lines.

Default is false.

pub fn with_ignore_invalid_headers(self, enabled: bool) -> Builder

Set whether HTTP/1 connections will silently ignored malformed header lines.

If this is enabled and a header line does not start with a valid header name, or does not include a colon at all, the line will be silently ignored and no error will be reported.

Default is false.

pub fn set_ignore_invalid_headers(&mut self, enabled: bool) -> &mut Builder

Set whether HTTP/1 connections will silently ignored malformed header lines.

If this is enabled and a header line does not start with a valid header name, or does not include a colon at all, the line will be silently ignored and no error will be reported.

Default is false.

pub fn maybe_with_max_headers(self, val: Option<usize>) -> Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn maybe_set_max_headers(&mut self, val: Option<usize>) -> &mut Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn with_max_headers(self, val: usize) -> Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn set_max_headers(&mut self, val: usize) -> &mut Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn without_max_headers(self) -> Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn unset_max_headers(&mut self) -> &mut Builder

Set the maximum number of headers.

When a request is received, the parser will reserve a buffer to store headers for optimal performance.

If server receives more headers than the buffer size, it responds to the client with “431 Request Header Fields Too Large”.

Note that headers is allocated on the stack by default, which has higher performance. After setting this value, headers will be allocated in heap memory, that is, heap memory allocation will occur for each request, and there will be a performance drop of about 5%.

Default is 100.

pub fn maybe_with_max_header_size(self, val: Option<usize>) -> Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn maybe_set_max_header_size(&mut self, val: Option<usize>) -> &mut Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn with_max_header_size(self, val: usize) -> Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn set_max_header_size(&mut self, val: usize) -> &mut Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn without_max_header_size(self) -> Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn unset_max_header_size(&mut self) -> &mut Builder

Set the maximum size in bytes of a request head, its request line included.

If the client sends a larger head, the server responds with “431 Request Header Fields Too Large” and closes the connection.

This also bounds the size of chunked trailers.

Default is None: the head is only bounded by the maximum buffer size, and trailers by 16 KiB.

pub fn maybe_with_lingering_close( self, linger: Option<LingeringClose>, ) -> Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn maybe_set_lingering_close( &mut self, linger: Option<LingeringClose>, ) -> &mut Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn with_lingering_close(self, linger: LingeringClose) -> Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn set_lingering_close(&mut self, linger: LingeringClose) -> &mut Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn without_lingering_close(self) -> Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn unset_lingering_close(&mut self) -> &mut Builder

Set the lingering close of a connection the server closes while the client may still be sending: while writing its response and after shutting down its side, the server reads and discards input within these bounds before closing the socket. The allowance is shared by both phases; if the total timeout or byte limit is reached before an idle end and the response is blocked, the connection ends with a write error. A client that went idle stops the lingering, not the response.

If idle_timeout >= timeout, the total limit wins even for an idle client and can abort a blocked response. Keep the idle timeout shorter to let idle clients continue reading; the defaults are 2 s and 30 s.

Closing with unread input makes the connection reset instead of ending cleanly, and a Windows client then drops the response it has not read yet: for instance a 413 sent while it is still uploading, or the 400 or 431 for a bad request head.

It only applies when input may be left unread: a request body the service did not read, buffered input such as a pipelined request, or a rejected request head. A clean close, a client that already ended its stream, an upgraded connection, a service or IO error, and a graceful shutdown of the server skip it.

Default is LingeringClose::default: up to 2 seconds without data and 30 seconds in total. None disables it.

pub fn maybe_with_header_read_timeout( self, timeout: Option<HeaderReadTimeout>, ) -> Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn maybe_set_header_read_timeout( &mut self, timeout: Option<HeaderReadTimeout>, ) -> &mut Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn with_header_read_timeout(self, timeout: HeaderReadTimeout) -> Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn set_header_read_timeout( &mut self, timeout: HeaderReadTimeout, ) -> &mut Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn without_header_read_timeout(self) -> Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn unset_header_read_timeout(&mut self) -> &mut Builder

Set the deadline for receiving a request head, from its first byte.

Defaults to HeaderReadTimeout::DEFAULT; None disables it.

pub fn maybe_with_idle_timeout(self, timeout: Option<IdleTimeout>) -> Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn maybe_set_idle_timeout( &mut self, timeout: Option<IdleTimeout>, ) -> &mut Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn with_idle_timeout(self, timeout: IdleTimeout) -> Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn set_idle_timeout(&mut self, timeout: IdleTimeout) -> &mut Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn without_idle_timeout(self) -> Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn unset_idle_timeout(&mut self) -> &mut Builder

Set the budget while no request is open nor a request head in progress, after which the connection closes.

Defaults to IdleTimeout::DEFAULT; None disables it.

pub fn maybe_with_writev(self, val: Option<bool>) -> Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.

pub fn maybe_set_writev(&mut self, val: Option<bool>) -> &mut Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.

pub fn with_writev(self, val: bool) -> Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.

pub fn set_writev(&mut self, val: bool) -> &mut Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.

pub fn without_writev(self) -> Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.

pub fn unset_writev(&mut self) -> &mut Builder

Set whether HTTP/1 connections should try to use vectored writes, or always flatten into a single buffer.

Note that setting this to false may mean more copies of body data, but may also improve performance when an IO transport doesn’t support vectored writes well, such as most TLS implementations.

Setting this to true will force rama_http_core to use queued strategy, which may eliminate unnecessary cloning on some TLS backends.

Default is auto. In this mode rama_http_core will try to guess which mode to use.