Expand description
HTTP header types
The module provides HeaderName, HeaderMap, and a number of types
used for interacting with HeaderMap. These types allow representing both
HTTP/1 and HTTP/2 headers.
The HeaderName type represents both standard header names as well as
custom header names. The type handles the case insensitive nature of header
names and is used as the key portion of HeaderMap. Header names are
normalized to lower case. In other words, when creating a HeaderName with
a string, even if upper case characters are included, when getting a string
representation of the HeaderName, it will be all lower case. This allows
for faster HeaderMap comparison operations.
The internal representation is optimized to efficiently handle the cases
most commonly encountered when working with HTTP. Standard header names are
special cased and are represented internally as an enum. Short custom
headers will be stored directly in the HeaderName struct and will not
incur any allocation overhead, however longer strings will require an
allocation for storage.
HeaderName has a max length of 32,768 for header names. Attempting to
parse longer names will result in a panic.
HeaderMap is a map structure of header names highly optimized for use
cases common with HTTP. It is a multimap structure, where each header name
may have multiple associated header values. Given this, some of the APIs
diverge from HashMap.
Just like HashMap in Rust’s stdlib, HeaderMap is based on Robin Hood
hashing. This algorithm tends to reduce the worst case search times in the
table and enables high load factors without seriously affecting performance.
Internally, keys and values are stored in vectors. As such, each insertion
will not incur allocation overhead. However, once the underlying vector
storage is full, a larger vector must be allocated and all values copied.
Unlike Rust’s HashMap, values in HeaderMap are deterministically
ordered. Roughly, values are ordered by insertion. This means that a
function that deterministically operates on a header map can rely on the
iteration order to remain consistent across processes and platforms.
HeaderMap uses an adaptive hashing strategy in order to efficiently handle
most common cases. All standard headers have statically computed hash values
which removes the need to perform any hashing of these headers at runtime.
The default hash function emphasizes performance over robustness. However,
HeaderMap detects high collision rates and switches to a secure hash
function in those events. The threshold is set such that only denial of
service attacks should trigger it.
HeaderMap can store a maximum of 32,768 headers (header name / value
pairs). Attempting to insert more will result in a panic.
A drain iterator for HeaderMap.
A view to all values stored in a single entry.
Represents an HTTP header field name
Represents an HTTP header field value.
An owning iterator over the entries of a HeaderMap.
A possible error when converting a HeaderName from another type.
A possible error when converting a HeaderValue from a string or byte
slice.
HeaderMap entry iterator.
HeaderMap mutable entry iterator
An iterator over HeaderMap keys.
A view into a single occupied location in a HeaderMap.
A possible error when converting a HeaderValue to a string representation.
A view into a single empty location in a HeaderMap.
An drain iterator of all values associated with a single header name.
An iterator of all values associated with a single header name.
A mutable iterator of all values associated with a single header name.
HeaderMap value iterator.
HeaderMap mutable value iterator
Advertises which content types the client is able to understand.
Advertises which character set the client is able to understand.
Advertises which content encoding the client is able to understand.
Advertises which languages the client is able to understand.
Marker used by the server to advertise partial request support.
Preflight response indicating if the response to the request can be
exposed to the page.
Preflight response indicating permitted HTTP headers.
Preflight header response indicating permitted access methods.
Indicates whether the response can be shared with resources with the
given origin.
Indicates which headers can be exposed as part of the response by
listing their names.
Indicates how long the results of a preflight request can be cached.
Informs the server which HTTP headers will be used when an actual
request is made.
Informs the server know which HTTP method will be used when the actual
request is made.
Indicates the time in seconds the object has been in a proxy cache.
Lists the set of methods support by a resource.
Advertises the availability of alternate services to clients.
Contains the credentials to authenticate a user agent with a server.
Specifies directives for caching mechanisms in both requests and
responses.
Indicates how caches have handled a response and its corresponding request.
Specifies directives that allow origin servers to control the behavior of CDN caches
interposed between them and clients separately from other caches that might handle the
response.
Controls whether or not the network connection stays open after the
current transaction finishes.
Indicates if the content is expected to be displayed inline.
Used to compress the media-type.
Used to describe the languages intended for the audience.
Indicates the size of the entity-body.
Indicates an alternate location for the returned data.
Indicates where in a full body message a partial message belongs.
Allows controlling resources the user agent is allowed to load for a
given page.
Allows experimenting with policies by monitoring their effects.
Used to indicate the media type of the resource.
Contains stored HTTP cookies previously sent by the server with the
Set-Cookie header.
Contains the date and time at which the message was originated.
Indicates the client’s tracking preference.
Identifier for a specific version of a resource.
Indicates expectations that need to be fulfilled by the server in order
to properly handle the request.
Contains the date/time after which the response is considered stale.
Contains information from the client-facing side of proxy servers that
is altered or lost when a proxy is involved in the path of the request.
Contains an Internet email address for a human user who controls the
requesting user agent.
Specifies the domain name of the server and (optionally) the TCP port
number on which the server is listening.
Makes a request conditional based on the E-Tag.
Makes a request conditional based on the modification date.
Makes a request conditional based on the E-Tag.
Makes a request conditional based on range.
Makes the request conditional based on the last modification date.
Content-Types that are acceptable for the response.
Allows the server to point an interested client to another resource
containing metadata about the requested resource.
Indicates the URL to redirect a page to.
Indicates the max number of intermediaries the request should be sent
through.
Indicates where a fetch originates from.
HTTP/1.0 header usually used for backwards compatibility.
Defines the authentication method that should be used to gain access to
a proxy.
Contains the credentials to authenticate a user agent to a proxy server.
Associates a specific cryptographic public key with a certain server.
Sends reports of pinning violation to the report-uri specified in the
header.
Indicates the part of a document that the server should return.
Contains the address of the previous web page from which a link to the
currently requested page was followed.
Governs which referrer information should be included with requests
made.
Informs the web browser that the current page or frame should be
refreshed.
The Retry-After response HTTP header indicates how long the user agent
should wait before making a follow-up request. There are two main cases
this header is used:
The |Sec-WebSocket-Accept| header field is used in the WebSocket
opening handshake. It is sent from the server to the client to
confirm that the server is willing to initiate the WebSocket
connection.
The |Sec-WebSocket-Extensions| header field is used in the WebSocket
opening handshake. It is initially sent from the client to the
server, and then subsequently sent from the server to the client, to
agree on a set of protocol-level extensions to use for the duration
of the connection.
The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g., HTTP
clients) that are being abused to send data to unsuspecting WebSocket
servers.
The |Sec-WebSocket-Protocol| header field is used in the WebSocket
opening handshake. It is sent from the client to the server and back
from the server to the client to confirm the subprotocol of the
connection. This enables scripts to both select a subprotocol and be
sure that the server agreed to serve that subprotocol.
The |Sec-WebSocket-Version| header field is used in the WebSocket
opening handshake. It is sent from the client to the server to
indicate the protocol version of the connection. This enables
servers to correctly interpret the opening handshake and subsequent
data being sent from the data, and close the connection if the server
cannot interpret that data in a safe manner.
Contains information about the software used by the origin server to
handle the request.
Used to send cookies from the server to the user agent.
Tells the client to communicate with HTTPS instead of using HTTP.
Informs the server of transfer encodings willing to be accepted as part
of the response.
Allows the sender to include additional fields at the end of chunked
messages.
Specifies the form of encoding used to safely transfer the entity to the
client.
Used as part of the exchange to upgrade the protocol.
Sends a signal to the server expressing the client’s preference for an
encrypted and authenticated response.
Contains a string that allows identifying the requesting client’s
software.
Determines how to match future requests with cached responses.
Added by proxies to track routing.
General HTTP header contains information about possible problems with
the status of the message.
Defines the authentication method that should be used to gain access to
a resource.
Marker used by the server to indicate that the MIME types advertised in
the content-type headers should not be changed and be followed.
Controls DNS prefetching.
Indicates whether or not a browser should be allowed to render a page in
a frame.
Stop pages from loading when an XSS attack is detected.