hyperium
Making `preserve_header_order` option official
Is your feature request related to a problem? Please describe.
Our use case of Hyper is using it as a proxy server. One of the difference from proxy test we found is the order of the headers in the response. The order of the headers may be different in some cases, and we are seeing diff when comparing w/ and w/o Hyper in front of the existing server.
Describe the solution you'd like
Making preserve_header_order to official as it is now ffi.
https://github.com/hyperium/hyper/blob/master/src/client/conn/http1.rs#L473-L476
Describe alternatives you've considered
Use preserve_header_order with ffi enabled.
However, I'd like to understand if there is any blocking issue to make the feature to official.
If there is any, I can also help.
Additional context Add any other context or screenshots about the feature request here.
Is your goal to provide a public API in hyper::ext? Or only to allow enabling a hidden extension, like HeaderCaseMap currently, which is only useful to forwarding in a proxy? Which is to say, a user cannot access the type, but it will exist in an incoming message and used by outgoing messages.
Or if you meant for a public type to manipulate in your own code, then a proposal for the design of the type's public methods would be needed.
Hi, My main goal is the first one, preserving the header case while forwarding the request and response.
Just to confirm, you mean the option without a public API (so you can't touch it at all). If so, the change should be pretty straightforward, a PR is welcome! Would you like to submit one?
Sounds good! I can definitely follow up with PR.
Just to clarify, I was thinking to only expose preserve_header_order API as a part of Client Conn Builder to allow the developer can choose whether they want to enable it or not.
If this is right, the changes are pretty straightforward as you said. Can you confirm we are on the same page?
I went through the codes in https://github.com/hyperium/hyper/blob/master/src/proto/h1/role.rs and found that there is no actual logic to use OriginalHeaderOrder in encoding the headers into the bytes. I believe it is because the feature was introduced to support the use case in https://github.com/hyperium/hyper/blob/master/src/ffi/http_types.rs.
I think it will take more time than expected since it requires new implementation in encoding part. Please let me know if I missed something.
That sounds right. We probably only added decoding support to fulfill the desire for curl. Encoding support could be added similar to the current "title cased" alternative mode.