It is no longer required, as we can use `<H as Header>::header_name()`.
BREAKING CHANGE: Implementations of Header will need to adjust the
header_name method. It no longer takes any arguments.
Currently headers are exported at many places. For example you can access
`Transfer-Encoding` header at `header`, `header::common` and
`header::common::transfer_encoding`. Per discussion on IRC with
@seanmonstar and @reem, all contents of headers will be exposed at `header`
directly. Parsing utilities will be exposed at `header::parsing`. Header
macros can now be used from other crates.
This breaks much code using headers. It should use everything it needs
directly from `header::`, encodings are exposed at `header::Encoding::`,
connection options are exposed at `header::ConnectionOption`.
- Some stray deriving -> derive changes
- use::{mod} -> use::{self}
- fmt.write -> fmt.write_str
This does not catch the last case of fmt.write_str in the
Show impl of a Header Item. This will need to be changed
separately.
- Includes ergonomic traits like IntoUrl and IntoBody, allowing easy
usage.
- Client can have a RedirectPolicy.
- Client can have a SslVerifier.
Updated benchmarks for client. (Disabled rust-http client bench since it
hangs.)
Previously, iter() returned (&str, HeaderView), which wasn't too useful
other than to write out to a stream. Checking for a certain header is
painful since header names are case-insensitive, but &str isn't. And
once found, you still couldn't do anything with a HeaderView other
format it.
Now, iter() returns a HeaderView, with methods is(), name(), and
value(). You can do `view.is::<ContentType>()` to check what header it
is. And you get the typed value out by calling
`view.value::<ContentType>()`, which will return an
`Option<ContentType>`, similar to `headers.get()`.
Headers also now implement Extend and FromIterator, so it's easier to
build new Headers objects by filtering out a few headers.
Because this changes .iter() to return HeaderView instead of a tuple,
this is a:
[breaking-change]
