Crate salvo::http::headers [−][src]
Expand description
Typed HTTP Headers
hyper has the opinion that headers should be strongly-typed, because that’s
why we’re using Rust in the first place. To set or get any header, an object
must implement the Header
trait from this module. Several common headers
are already provided, such as Host
, ContentType
, UserAgent
, and others.
Why Typed?
Or, why not stringly-typed? Types give the following advantages:
- More difficult to typo, since typos in types should be caught by the compiler
- Parsing to a proper type by default
Defining Custom Headers
Implementing the Header
trait
Consider a Do Not Track header. It can be true or false, but it represents
that via the numerals 1
and 0
.
extern crate http;
extern crate headers;
use headers::{Header, HeaderName, HeaderValue};
struct Dnt(bool);
impl Header for Dnt {
fn name() -> &'static HeaderName {
&http::header::DNT
}
fn decode<'i, I>(values: &mut I) -> Result<Self, headers::Error>
where
I: Iterator<Item = &'i HeaderValue>,
{
let value = values
.next()
.ok_or_else(headers::Error::invalid)?;
if value == "0" {
Ok(Dnt(false))
} else if value == "1" {
Ok(Dnt(true))
} else {
Err(headers::Error::invalid())
}
}
fn encode<E>(&self, values: &mut E)
where
E: Extend<HeaderValue>,
{
let s = if self.0 {
"1"
} else {
"0"
};
let value = HeaderValue::from_static(s);
values.extend(std::iter::once(value));
}
}
Modules
Authorization header and types.
Structs
Accept-Ranges
header, defined in RFC7233
Access-Control-Allow-Credentials
header, part of
CORS
Access-Control-Allow-Headers
header, part of
CORS
Access-Control-Allow-Methods
header, part of
CORS
The Access-Control-Allow-Origin
response header,
part of CORS
Access-Control-Expose-Headers
header, part of
CORS
Access-Control-Max-Age
header, part of
CORS
Access-Control-Request-Headers
header, part of
CORS
Access-Control-Request-Method
header, part of
CORS
Allow
header, defined in RFC7231
Authorization
header, defined in RFC7235
Cache-Control
header, defined in RFC7234
Connection
header, defined in
RFC7230
A Content-Disposition
header, (re)defined in RFC6266.
Content-Encoding
header, defined in
RFC7231
Content-Length
header, defined in
RFC7230
Content-Location
header, defined in
RFC7231
Content-Range, described in RFC7233
Content-Type
header, defined in
RFC7231
Cookie
header, defined in RFC6265
Date
header, defined in RFC7231
ETag
header, defined in RFC7232
Errors trying to decode a header.
The Expect
header.
Expires
header, defined in RFC7234
A set of HTTP headers
Represents an HTTP header field name
Represents an HTTP header field value.
The Host
header.
If-Match
header, defined in
RFC7232
If-Modified-Since
header, defined in
RFC7232
If-None-Match
header, defined in
RFC7232
If-Range
header, defined in RFC7233
If-Unmodified-Since
header, defined in
RFC7232
Last-Modified
header, defined in
RFC7232
Location
header, defined in
RFC7231
The Origin
header.
The Pragma
header defined by HTTP/1.0.
Proxy-Authorization
header, defined in RFC7235
Range
header, defined in RFC7233
Referer
header, defined in
RFC7231
Referrer-Policy
header, part of
Referrer Policy
The Retry-After
header.
The Sec-Websocket-Accept
header.
The Sec-Websocket-Key
header.
The Sec-Websocket-Version
header.
Server
header, defined in RFC7231
Set-Cookie
header, defined RFC6265
StrictTransportSecurity
header, defined in RFC6797
TE
header, defined in
RFC7230
Transfer-Encoding
header, defined in
RFC7230
Upgrade
header, defined in RFC7230
User-Agent
header, defined in
RFC7231
Vary
header, defined in RFC7231
Traits
A trait for any object that will represent a header field and value.
An extension trait adding “typed” methods to http::HeaderMap
.