Typed Headers?

[seanmonstar]

Work has been progressing on a typed headers system to replace what hyper had prior to v0.12. Some questions arise as to where this stuff should "live".

• @ashleygwilliams is owner of the headers crate name, and has agreed to transfering the name if we wish to use it for this.
• @carllerche is the owner of the http-headers crate name, and has suggested we could publish there, as the name headers might be too vague.
• We could include them directly in http.
  • It's certainly tempting to be able to use them directly, like let conlen = http::header::ContentLength(450);, and perhaps it should be the eventual goal.
  • However, I believe the typed headers are less stable than the core HTTP types. The goal of http was to have a stable crate that the ecosystem can use to be "generic" over HTTP implementations. Therefore, breaking changes must be exceptional. I have taken much effort to reduce the exposed surface area in the new crate API, specifically to reduce the need for breaking changes. Still, I would have to have missed something and be stuck with it.
  • It's been suggested that the current http API could be moved to http-core and re-exported, and have the stability be stronger on http-core than http.

See also #136.

[carllerche]

The header implementations are generally useful. I think it would be valuable to provide them as part of http. My preferred plan is to:

• Move stable types to http-core.
• Release typed headers as http-headers (headers is a bit generic).
• Convert http to a facade.

most libraries will only depend on the core types. This strategy is being adopted to allow breaking change iterations while maintaining stability of core types.

[davidbarsky]

+1 to @carllerche's plan. The other thing that I'd like—and this is mostly optional/depends on stability of functionality in the headers crate—is the ability to define custom headers without waiting for additional features in const fn. Building on the discussion in hyperium/headers#29, a compromise that I'd be happy with is a highly unstable, off-by-default feature flag that defines fn name() -> HeaderName for the Header trait until the required functionality lands in rustc. Alternatively, I'd be happy with a similarly unstable feature flag that exposes functionality similar to standard_headers!. Thoughts, @seanmonstar?

[sfackler]

You should be able to use lazy_static to make 'static HeaderName instances for custom headers.

[dekellum]

See also #174, which included an example (and slightly weird syntax requirement) with lazy_static.

[seanmonstar]

@sfackler the trait was adjusted to have const NAME: &'static HeaderName instead of fn name(), which means types made with lazy_static don't actually fit as a constant, I believe.

[sfackler]

Oh yeah, that would be a problem. Is the name actually used in a const context? fn name() -> &'static HeaderName seems like it would work just fine, right?

[davidbarsky]

Well, it might be useful for me to explain why I care about this feature. Namely—I'd like to have typed versions of the headers the AWS Lambda Runtime API returns without all sorts of stringly-typed interfaces. Like I said previously, I'd be happy to opt into some sort of unstable interface/feature flag so that our customers can interact with typed values.