Creating headers without creating Header structs

[gtolle]

As part of my little rest_client project, I'm interested in making it possible for the user to specify custom headers for a request using string tuples, like ("X-Modhash", "foobar").

I'm totally impressed with this typed header design, especially on the server side where you've defined a set of headers that you're willing to process.

But, I don't see a way for a client to set a new header into the Headers object without actually creating a new struct that implements the Header trait and defines the name of the header as a static string (e.g. "X-Modhash") returned by fn header_name.

This seems to make it impossible for a client to specify a new header at runtime without creating a new struct at compile-time.

I took a stab at using macros to do it, but my Rust knowledge hit a wall. So, I thought I'd ask.

How would you implement a custom header on the client side without requiring the user to write a ~16 line struct/impl definition for that header?

Thanks!

[reem]

There are really two potential answers to this question, as I see them:

1. You use the forthcoming raw Headers instead of the higher level API supplied by normal hyper. The RawHeaders API will be much more amenable to this sort of thing.
2. You await a new, more ergonomic raw API in the new top-level Headers supplied by normal hyper, which will have facilities for the runtime insertion of headers from raw strings.

Alternatively, you expose a typed interface instead of a (&str, &str) one. This would work by you just receiving an H: Header and using the typed interface of hyper headers instead of the raw one.

I recognize that this doesn't solve your problem right now, and ergonomic header access is something we have been thinking about a lot and hope to solve in the near future.

[gtolle]

Thanks for the quick reply and suggestions.

I'll definitely look into the RawHeaders API when it arrives, and keep an eye on issue #50.

This is just a fun side project for me, so no worries about not solving my problem. :)

[seanmonstar]

I'd emphasize the typed API, as it's cleaner and safer. Using it means less
crashes for everyone. I'd recommend that you provide both APIs, so that
people who want the safety can use it.

However, as @reem mentioned, we do want to provide a raw interface, when
it's not possible to know headers at compile time. Main driver is Servo,
exposing things like xhr.getResponseHeader("foobaz") in the DOM.

[gtolle]

That makes sense. I'll definitely look into that.

Side question: I'm implementing my own Authorization header now, and I'm finding myself wanting to reuse the from_one_raw_str function you've already written. Any objection to making that pub?

[reem]

@gtolle I don't see why not other than it should then be moved into a util module inside of header::common instead of being at the top level. I would also be happy to accept a PR with an implementation of the Authorization header as a relatively common header we should have support for in hyper.

[s-panferov]

+1 for PR, i like to see this header too

[seanmonstar]

There exists headers.set_raw(&str, Vec<Vec<u8>>).