Skip to content
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.

Support per-connection data for services #64

Open
mzabaluev opened this issue Apr 5, 2019 · 3 comments
Open

Support per-connection data for services #64

mzabaluev opened this issue Apr 5, 2019 · 3 comments

Comments

@mzabaluev
Copy link
Contributor

Sometimes it's useful to associate connection-level information with requests and/or service instances. Currently, the MakeService implementation that is passed to a Server upon construction does not receive any data for service instances to be able to distinguish transport connections. The Service instances only deal with HTTP request objects that, by design, do not provide transport information. It would be nice to be able to pass per-connection information to the services somehow.

@mzabaluev mzabaluev changed the title support per-connection data for services Support per-connection data for services Apr 5, 2019
@mzabaluev
Copy link
Contributor Author

Some thoughts on whether this requirement is unusual.
In general, there is no obligation for request streams multiplexed over a single HTTP/2 connection to belong to a single logical peer entity, and there are probably scenarios where this assumption breaks (proxies?). One important use case is TLS connections with client authentication, where trusted information about the peer can be retrieved from the connection's context.

@LucioFranco
Copy link
Member

@mzabaluev we have been thinking about adding a Connection trait to tower-http that will bridge the gap between connection and transport, that said, it should be possible to wrap a MakeService and MakeConnection to provide the context you need.

@seanmonstar
Copy link
Contributor

This is possible already in hyper, where the MakeService is provided a reference to the connection so it can collect what it needs to create a Service.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants