Design: connection adapters

[natemcmaster]

Follow up to #1495 and #1664.

Open questions:

• How does an adapter report metadata about itself? e.g. does it support TLS? HTTP2? Logger name?
• How does kestrel expose connection I/O to adapters? IPipeReader/ISocketOutput, Stream, or both?

[Drawaes]

There are a couple of things that "leak" out of abstraction in the Tls 1.3 standard that might be worth considering

• 0RTT Data, it is available but can be replayed, therefore recommendation is that you would limit it to say "Get" requests but the TLS layer doesn't know that it's a get until it is parsed
• TLS 1.3 has an "export" key data facility, eg you should use this to generate secrets in the applicaiton rather than some other method as it binds the secret back to the secure session generation
• TLS can give a different "host" than the client actually hit
• TLS could use one of many server certificate, would this be useful for Kestrel to know?

Many of these might be solved through "Features" but it's worth thinking about during the design.

Happy to tell you more if you are interested

[tmds]

Related open design question:
how transport can expose ihttpsendfile support (#1593)

[davidfowl]

Unrelated. File another issue please. We need to expose the feature collection to the Transport.

[Tratcher]

@davidfowl how's that going to work? The feature collection is per request, where the transports don't know about individual requests.

[davidfowl]

@Tratcher I'm not sure you'll be able to implement IHttpSendFileFeature but transports have a similar view to connection filters (which do get access to the feature collection). Anyways this is the wrong issue for that discussion.

[Drawaes]

Today the filters get access by registering a call back that is fired per request to build the feature collection

[tmds]

created issue for Transport SendFile feature: #1673

[davidfowl]

We're nuking these infavor of connection middleware