Support for cookies

[bentoi]

We could add a cookie interceptor and middleware to support cookies. It would be the same as HTTP cookies except that cookies would be supported for both client->server invocations and server->client invocations. Like HTTP, it would be supported with two fields: Set-Cookie and Cookie.

[bernardnormier]

Interceptors, middleware and icerpc reverse proxies can define icerpc fields to communicate with each other.

It's not clear to me why we'd want to use http cookies for such communications--with presumably http's cookie syntax and format--as opposed to defining our own fields.

[bentoi]

Http cookies use Http request/response headers and are formatted as strings. icerpc cookies would use request/response fields and can just contain binary data.

Cookies are well understood and used a lot for web applications. I think they could also be useful for RPC applications. A reverse proxy implementation would likely use them as well to provide session affinity.

[bentoi]

Note that it's the cookie value which would be transferred as bytes. A cookie would typically be encoded as a Slice2 struct with additional attributes:

struct Cookie
{
     value: sequence<uint8>,
     expires: Date,
     maxAge: TimeSpan,
     ...
}

The advantage of cookies is that the server-side can rely on the client-side supporting cookies.

[pepone]

I think an interesting bit about how cookies work is the domain and path, clients receive cookies from multiple peers and a client knows what cookies to set with a given request.