Better solution for "enum" Headers like Encoding

[hyperium]

Better solution for "enum" Headers like Encoding

[reem]

I think this is fine, since you can choose your own representation for a Header if you want better support for a non-standard value for that Header.

[reem]

However, I think we have to be very careful with Headers like TransferEncoding, Date, and Host, which are baked into hyper.

[seanmonstar]

Hm, oh right! The hyper server uses those headers internally to meet the spec, and if someone wants a completely different struct of handle TransferEncoding or something, then the Typed return value would be wrong (I think currently that would be a downcast to the wrong type), and there'd be no more Raw to rebuild a different format.

I'm starting to think that design in teepee (keeping raw around even after parsing) makes more sense... I just was hoping to save on memory.

[reem]

Uh oh, you're right. It just occurred to me that the existing scheme is entirely unsafe. If you try to access a header through two representations, you'll get an undefined transmute!

[reem]

This is fixable by tracking TypeId, but I don't see a good way to allow access under two representations in the same app - if you use one representation you can make a change that might not be represented in the raw header. i.e. I can write the transfer encoding to gzip using one representation, but another representation still sees the original encoding.