Struct Http1OptionsBuilder 

pub struct Http1OptionsBuilder { /* private fields */ }

Builder for Http1Options.

Implementations

impl Http1OptionsBuilder

pub fn http09_responses(self, enabled: bool) -> Self

Set the http09_responses field.

pub fn writev(self, writev: Option<bool>) -> Self

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 crate::core: to use queued strategy which may eliminate unnecessary cloning on some TLS backends

Default is auto. In this mode crate::core: will try to guess which mode to use

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

Set the maximum number of headers.

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

If client receives more headers than the buffer size, the error “message header too large” is returned.

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 response, and there will be a performance drop of about 5%.

Default is 100.

pub fn read_buf_exact_size(self, sz: Option<usize>) -> Self

Sets the exact size of the read buffer to always use.

Note that setting this option unsets the max_buf_size option.

Default is an adaptive read buffer.

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

Set the maximum buffer size for the connection.

Default is ~400kb.

Note that setting this option unsets the read_exact_buf_size option.

Panics

The minimum value allowed is 8192. This method panics if the passed max is less than the minimum.

pub fn allow_spaces_after_header_name_in_responses(self, enabled: bool) -> Self

Set whether HTTP/1 connections will accept spaces between header names and the colon that follow them in responses.

You probably don’t need this, here is what RFC 7230 Section 3.2.4. has to say about it:

No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request). A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.

Default is false.

pub fn ignore_invalid_headers_in_responses(self, enabled: bool) -> Self

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 allow_obsolete_multiline_headers_in_responses(self, value: bool) -> Self

Set the allow_obsolete_multiline_headers_in_responses field.

pub fn build(self) -> Http1Options

Build the Http1Options instance.

Trait Implementations

impl Debug for Http1OptionsBuilder

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.