Set-Cookie header should have a more structured wrapper

[kamalmarhubi]

This is an analog of #1145 which was about the Cookie header. The current type is a direct wrapper over the vector of Set-Cookie headers. From some client uses, it would be nice to have a cookie name based lookup, as well as accessors for the "standard" cookie attributes. For server use, it would be nice to expose a builder-type interface to add cookies and set attributes.

It needs some thought to avoid allocations / copies to the degree that makes sense / impossible, but I think the convenience is worth a small penalty for many uses. A possible rough interface:

impl SetCookie {
  pub fn get<K: AsRef<[u8]>(&self, key: K) -> Option<CookieValue> { unimplemented!(); }
  pub fn add<K: AsRef<[u8]>(&self, key: K) -> CookieBuilder  { unimplemented!(); }
}

pub struct CookieValue(/* TBD */);
impl CookieValue {
  pub fn http_only(&self) -> bool  { unimplemented!(); }
  pub fn domain(&self) -> Option<&str>  { unimplemented!(); }
  pub fn extension(&self) -> Option<&str>  { unimplemented!(); }
  // ...
}

pub struct CookieBuilder(/* TBD */);
impl CookieBuilder {
  pub fn http_only(&mut self, http_only: bool) -> &mut CookieBuilder  { unimplemented!(); }
  pub fn domain<S: AsRef<str>>(&mut self, domain: S) -> &mut CookieBuilder  { unimplemented!(); }
  pub fn extension(&mut self, extension: S) -> &mut CookieBuilder  { unimplemented!(); }
  // ...
}

// Maybe for ergonomics?
impl Drop for CookieBuilder {
  pub fn drop(&mut self) {
    // Add the cookie to the storage in `SetCookie`.
  }
}

[seanmonstar]

Seems like a good goal. Perhaps CookieValue is CookieValue<'a>, which borrows from SetCookie?

[kamalmarhubi]

Yeah, was thinking something like that. So long as you think it's a good direction, I'll take a crack at it.

And if the Drop ergonomics thing makes sense, then CookieBuilder<'a> with &'a mut SetCookie inside. Not so sure about that one; thoughts?

[kamalmarhubi]

Oh and one thing I'm unclear on: how much of the "typed header" stuff will remain in Hyper after switching to the http crate's types?

[seanmonstar]

Oh, I hadn't noticed the Drop behavior. Hm, on one hand, that seems clever, but on the other, it seems surprising...

For 0.12, hyper will have removed hyper::header, and all that was in it will be published as a separate crate (with an altered API to accommodate working with HeaderMaps).

[kamalmarhubi]

Hm, on one hand, that seems clever, but on the other, it seems surprising...

Yeah, that was my thought too. Thinking a bit more, it should be possible to avoid a "commit" step.

For 0.12, hyper will have removed hyper::header, and all that was in it will be published as a separate crate (with an altered API to accommodate working with HeaderMaps).

What's the timeline for this? Is it worth implementing this against 0.11?

[seanmonstar]

What's the timeline for this? Is it worth implementing this against 0.11?

There is the 0.12 milestone, but in short, it is waiting for any breaking changes for futures and the tokio crates, to be combined with the breaking change of using http. It will likely be a while, possible a couple months, so this feature could easily fit into 0.11.

[seanmonstar]

For now, the new version of hyper won't be including the typed headers directly, so I'm closing this here as a won't fix.