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

Struct Builder

pub struct Builder { /* private fields */ }

Available on crate features http and http-full 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 with_header_read_timeout(self, read_timeout: Duration) -> Builder

Set a timeout for reading client request headers. If a client does not transmit the entire header within this time, the connection is closed.

Requires a [Timer] set by [Builder::timer] to take effect. Panics if header_read_timeout is configured without a [Timer].

Default is 30 seconds.

pub fn set_header_read_timeout( &mut self, read_timeout: Duration, ) -> &mut Builder

Set a timeout for reading client request headers. If a client does not transmit the entire header within this time, the connection is closed.

Requires a [Timer] set by [Builder::timer] to take effect. Panics if header_read_timeout is configured without a [Timer].

Default is 30 seconds.

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