Struct ParserConfig

Source

pub struct ParserConfig { /* private fields */ }

Expand description

Parser configuration.

Implementations§

Source §

impl ParserConfig

Source

pub fn allow_spaces_after_header_name_in_responses( &mut self, value: bool, ) -> &mut Self

Sets whether spaces and tabs should be allowed after header names in responses.

Source

pub fn allow_multiple_spaces_in_request_line_delimiters( &mut self, value: bool, ) -> &mut Self

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

§Background

The latest version of the HTTP/1.1 spec allows implementations to parse multiple whitespace characters in place of the SP delimiters in the request line, including:

SP, HTAB, VT (%x0B), FF (%x0C), or bare CR

This option relaxes the parser to allow for multiple spaces, but does not allow the request line to contain the other mentioned whitespace characters.

Source

pub fn multiple_spaces_in_request_line_delimiters_are_allowed(&self) -> bool

Whether multiple spaces are allowed as delimiters in request lines.

Source

pub fn allow_multiple_spaces_in_response_status_delimiters( &mut self, value: bool, ) -> &mut Self

Sets whether multiple spaces are allowed as delimiters in response status lines.

§Background

The latest version of the HTTP/1.1 spec allows implementations to parse multiple whitespace characters in place of the SP delimiters in the response status line, including:

SP, HTAB, VT (%x0B), FF (%x0C), or bare CR

This option relaxes the parser to allow for multiple spaces, but does not allow the status line to contain the other mentioned whitespace characters.

Source

pub fn multiple_spaces_in_response_status_delimiters_are_allowed(&self) -> bool

Whether multiple spaces are allowed as delimiters in response status lines.

Source

pub fn allow_obsolete_multiline_headers_in_responses( &mut self, value: bool, ) -> &mut Self

Sets whether obsolete multiline headers should be allowed.

This is an obsolete part of HTTP/1. Use at your own risk. If you are building an HTTP library, the newlines (\r and \n) should be replaced by spaces before handing the header value to the user.

§Example

let buf = b"HTTP/1.1 200 OK\r\nFolded-Header: hello\r\n there \r\n\r\n";
let mut headers = [httparse::EMPTY_HEADER; 16];
let mut response = httparse::Response::new(&mut headers);

let res = httparse::ParserConfig::default()
    .allow_obsolete_multiline_headers_in_responses(true)
    .parse_response(&mut response, buf);

assert_eq!(res, Ok(httparse::Status::Complete(buf.len())));

assert_eq!(response.headers.len(), 1);
assert_eq!(response.headers[0].name, "Folded-Header");
assert_eq!(response.headers[0].value, b"hello\r\n there");

Source

pub fn obsolete_multiline_headers_in_responses_are_allowed(&self) -> bool

Whether obsolete multiline headers should be allowed.

Source

pub fn allow_space_before_first_header_name(&mut self, value: bool) -> &mut Self

Sets whether white space before the first header is allowed

This is not allowed by spec but some browsers ignore it. So this an option for compatibility. See https://github.com/curl/curl/issues/11605 for reference

§Example

let buf = b"HTTP/1.1 200 OK\r\n Space-Before-Header: hello there\r\n\r\n";
let mut headers = [httparse::EMPTY_HEADER; 1];
let mut response = httparse::Response::new(&mut headers[..]);
let result = httparse::ParserConfig::default()
    .allow_space_before_first_header_name(true)
    .parse_response(&mut response, buf);
assert_eq!(result, Ok(httparse::Status::Complete(buf.len())));
assert_eq!(response.version.unwrap(), 1);
assert_eq!(response.code.unwrap(), 200);
assert_eq!(response.reason.unwrap(), "OK");
assert_eq!(response.headers.len(), 1);
assert_eq!(response.headers[0].name, "Space-Before-Header");
assert_eq!(response.headers[0].value, &b"hello there"[..]);

Source

pub fn space_before_first_header_name_are_allowed(&self) -> bool

Whether white space before first header is allowed or not

Source

pub fn parse_request<'buf>( &self, request: &mut Request<'_, 'buf>, buf: &'buf [u8], ) -> Result<usize>

Parses a request with the given config.

Source

pub fn parse_request_with_uninit_headers<'headers, 'buf>( &self, request: &mut Request<'headers, 'buf>, buf: &'buf [u8], headers: &'headers mut [MaybeUninit<Header<'buf>>], ) -> Result<usize>

Parses a request with the given config and buffer for headers

Source

pub fn ignore_invalid_headers_in_responses(&mut self, value: bool) -> &mut Self

Sets whether invalid header lines should be silently ignored in responses.

This mimicks the behaviour of major browsers. You probably don’t want this. You should only want this if you are implementing a proxy whose main purpose is to sit in front of browsers whose users access arbitrary content which may be malformed, and they expect everything that works without the proxy to keep working with the proxy.

This option will prevent ParserConfig::parse_response from returning an error encountered when parsing a header, except if the error was caused by the character NUL (ASCII code 0), as Chrome specifically always reject those, or if the error was caused by a lone character \r, as Firefox and Chrome behave differently in that case.

The ignorable errors are:

empty header names;
characters that are not allowed in header names, except for \0 and \r;
when allow_spaces_after_header_name_in_responses is not enabled, spaces and tabs between the header name and the colon;
missing colon between header name and value;
when allow_obsolete_multiline_headers_in_responses is not enabled, headers using obsolete line folding.
characters that are not allowed in header values except for \0 and \r.

If an ignorable error is encountered, the parser tries to find the next line in the input to resume parsing the rest of the headers. As lines contributing to a header using obsolete line folding always start with whitespace, those will be ignored too. An error will be emitted nonetheless if it finds \0 or a lone \r while looking for the next line.

Source