Migrate hyper::header to its own crate

[DiamondLovesYou]

rust-ppapi maintainer here. rust-ppapi needs to be able to handle header formats correctly, but doesn't need all of Hyper (ie doesn't need the server + client parts). I'd like to have rust-ppapi just depend on the header portions of hyper, because the Pepper API has it's own http client API.

[seanmonstar]

Hm, Yea. I could make 3 sub crates, hyperc, hyperd, and hyperp, or
whatever, and bundle them all as hyper.

I don't think I want them in separate repos and such, though.

On Wed, Dec 10, 2014, 9:09 AM Richard Diamond notifications@github.com
wrote:

rust-ppapi maintainer here. rust-ppapi needs to be able to handle header
formats correctly, but doesn't need all of Hyper (ie doesn't need the
server + client parts). I'd like to have rust-ppapi just depend on the
header portions of hyper, because the Pepper API has it's own http client
API.

—
Reply to this email directly or view it on GitHub
#189.

[DiamondLovesYou]

Hm, Yea. I could make 3 sub crates, hyperc, hyperd, and hyperp, or
whatever, and bundle them all as hyper.

That would be excellent!
Though I'd bikeshead and say should be named hyper-client, hyper-header, and hyper-server.

I don't think I want them in separate repos and such, though.
That's not needed. Checkout rust-openssl's (Cargo.toml)[https://github.com/sfackler/rust-openssl/blob/master/Cargo.toml]. It explicitly sets the path of the dep.

[seanmonstar]

Yea I figured hyperclient -> hyperc, hyperserver -> hyperd (daemon), and hyperp for hyper protocol, since it would include more than just headers. This is because the headers depend on HttpError, Method, etc.

[DiamondLovesYou]

I suppose I can live with that.

[pyfisch]

It looks to me like Cargo got support for sub-crates: http://doc.crates.io/guide.html#path-dependencies

I propose to split Hyper into hyperprotocol, hyperclient, hyperserver and maybe hypernet.

[jimmycuadra]

Would there be any disadvantages to extracting the status and header modules into their own crates? What about giving them generic (non-"hyper") names? It'd be great to have generic types for these concepts in the Rust ecosystem (like we have the url crate) that could be used by downstream crates without having to tie their APIs to anything specific to Hyper.

[mikedilger]

Case in point: my email/mime creation crate depends on hyper, and it has nothing to do with HTTP.

I don't think splitting it up into lots of tiny crates makes sense, but headers/mime should really be separate.

[brendanzab]

Yeah, looking at the IANA list of headers, it seems that headers span more than just http. I can also see that we are missing many of them! It would be nice to see if we could split them out and do some more rgourous testing of our implementation coverage, perhaps even testing to see how many we implement based on their supplied CSV file.

[seanmonstar]

This will be done as part of the 0.12 release. When the rest of the types are replaced with http types, that means things by default will be using http::HeaderMap.

This will mean a change to the API is likely needed, perhaps as just a way to get and set typed values by taking &/&mut HeaderMap.

Also needs a name. Some ideas:

• headers (currently exists, but looks like it may have just been an experiment. Perhaps Ashley would be interested in a transfer?)
• helmet (protecting your head(ers)?)
• visor (enhancing your head(ers)?)

[mehcode]

My vote would be http_headers and then http/headers if/when Cargo supports sub-crates.

Rationale is: The base http package provides base HTTP types. The http_headers package provides additional types for HTTP headers.

[seanmonstar]

http_headers is also currently claimed (perhaps abandoned?).

[tshepang]

sad when people do this https://docs.rs/http_headers/0.0.2/src/http_headers/lib.rs.html

[sfackler]

I've started prototyping this: https://github.com/sfackler/typed-headers

[mbilker]

The header API is now available through http::header. hyper::header has been removed.

[asonix]

It seems that there is an API available through http::header, but it isn't as extensive as the one that used to be in hyper. Are there plans to change this, or is parsing header values (such as content-disposition) left to downstreams?

[dekellum]

I've been successfully using hyper 0.11.x with the compat feature, CompatFutureResponse and the http crate types. In most cases the byte-oriented HeaderMap best fits my uses. However, in certain cases I'm also passing http::header::HeaderValue to hyper::header module types to use its typed parsing facilities, as in the following.

Paraphrased from body-image/src/client.rs:

use self::hyper::header::{ContentEncoding, ContentLength,
                          Encoding as HyEncoding,
                          Header, TransferEncoding, Raw};

let encodings = headers.get_all(http::header::CONTENT_ENCODING);

for v in encodings {
    if let Ok(v) = ContentEncoding::parse_header(&Raw::from(v.as_bytes())) {
        for av in v.iter() {
            //...
        }
    }
}

To prepare for hyper 0.12.x and take advantage of some other niceties with tokio reform, I've started attempting the port to the master branch of hyper. The typed hyper::header module is of course gone. Is there any plans or interest in (re-)offering this typed header facility as a standalone crate that can be used in a similar way as above? Possibly with some more direct support for the http crate types? Or would you suggest I independently implement the subset of the parsing I need?

This issue dates from 2014 and I suspect the release and migration to the http crate satisfies the original request, but I didn't want to create a duplicate before asking. Please advise.

[dekellum]

I forked a hyperx crate, with the header module from 0.11.x branch (76fdbcf) and have been using this to ease my migration and testing with tokio (reform) and hyper master branch (0.12-pre).

https://docs.rs/hyperx
https://crates.io/crates/hyperx/0.12.0

@seanmonstar please consider this as a prototype and contribution to some future official extraction of the module. So far I haven't done anything to make this play nicer with the http::header types.

Edit: Add repo link: dekellum/hyperx

[seanmonstar]

Update: I've made https://github.com/hyperium/headers that pulls the 0.11.x typed headers into its own crate. The name is provisional, the purpose is just to try to consolidate effort and conversations in a single place.

[jplatte]

Since hyperium/headers exists and is actively being worked on, this can probably be closed, right?