Open Fishrock123 opened 4 years ago
Notes:
RequestBuilder
impl AsMut<Headers>
but this still breaks the chaining pattern.tide::ResponseBuilder
.I don't think it's too bad for the low level API exposed from http-types
— it does what it needs to. Though I def agree this is not a great end user API, and we should def look to improve.
Instead I'd be curious what we could do at the Surf level to make this nicer. Could there be some simple middleware that would make this intuitive to use? We talked about a cookie store middleware a while ago too. Perhaps a pairing there could create a nice end-user API?
I don't follow, why should someone have to install a middleware to set typed headers easily? This is not just about auth.
Just to be clear, my suggestion here is to hopefully avoid something like: .header()
& .header_typed()
or .header_parts()
& .header(Typed)
. Although I suppose the latter wouldn't be terrible, but also not much better than today.
I concur on this general problem but figured we'd sort this out after most of the headers were defined. It would be nice if there was a trait of some sort that all of these headers conformed to, and a way to invert applying the headers. so instead of header.apply(&mut request), we'd request.something(header), where header is impl Header, and which sets both the name and value(s)
For posterity, tracking issue for typed headers progress: https://github.com/http-rs/http-types/issues/99
This is not very nice:
(From https://github.com/squamishaccess/squamishaccess-signup-function-rs/blob/6c445916760a4db21da80c732fbe8e9c704c1bd1/src/main.rs#L168-L172)
I think something like
ToHeaderPair
may be ideal? We could implement that for a tuple and for typed headers.This would be different than
ToHeaderValues
since it would also have the header name.@yoshuawuyts thoughts?