http filters: add request local storage (RLS)

[mattklein123]

Implementation should be similar to how TLS works but built on top of the HTTP filter stack.

[mattklein123]

@alyssawilk this is the issue I was chatting with you about. I think you want "CLS" (connection local storage). IMO it could work very much like TLS where filters at config load time allocate a slot: https://github.com/envoyproxy/envoy/blob/master/include/envoy/thread_local/thread_local.h

[htuch]

Would there be any relationship with connection/request metadata? Or do we want to treat them as read-only and a distinct concept.

[mattklein123]

We could probably put the metadata into a slot. Not sure. Needs some thinking. This is a way that filters can pass arbitrary data between.

[mattwoodyard]

+1 for a unified CLS and RLS design. I've implemented both internally, but with the current APIs its not the cleanest design.

[jmarantz]

This is a cool idea. Is this also a place where request-headers, response-headers, and possibly response-body can go, rather than passing them around discretely as needed? It's nice to have the arbitrary slots but requests also have some semantics that could be held directly.

[mattklein123]

Is this also a place where request-headers, response-headers, and possibly response-body can go, rather than passing them around discretely as needed?

We can consider this, but probably not for data, as the idea of the filter API for data is to allow inline modification before the connection manager handles buffering, etc. I'm not sure it's really worth the API changes for headers either but certainly something to think about.