Skip to content

Add a new field, transportSpecific to ServerContext #2228

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 2, 2025

Conversation

jtdavey
Copy link
Contributor

@jtdavey jtdavey commented Apr 30, 2025

Motivation:

Currently there's no way to plumb through details from the transport level to a request handler. Adding this field allows transports, such as the nio transport, to add the peer certificate to the server context when using mTLS.

From there there it's easy for an interceptor to take this data and propogate it forward to a request handler.

Modifications:

This PR adds a single field to the ServerContext that transports can use

Result:

A new field will be accessible to transports and consumers of the API

Motivation:

Currently there's no way to plumb through details from the transport
level to a request handler. Adding this field allows transports, such as
the nio transport, to add the peer certificate to the server context
when using mTLS.

From there there it's easy for an interceptor to take this data and
propogate it forward to a request handler.

Modifications:

This PR adds a single field to the ServerContext that transports can use

Result:

A new field will be accessible to transports and consumers of the API
Copy link

linux-foundation-easycla bot commented Apr 30, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

///
/// An example of what this field can be used for, would be to store
/// things like a peerCertificate from a mTLS connection
public var transportSpecific: (any Sendable)?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this some more, rather than any Sendable can you define a public protocol TransportSpecific: Sendable {} nested within ServerContext and use that instead?

It has a few advantages:

  1. Compiler helps users out a little more
  2. It's easier to document and easier for users to find implementations.

@glbrntt glbrntt added the 🆕 semver/minor Adds new public API. label May 1, 2025
Copy link
Collaborator

@glbrntt glbrntt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks @jtdavey!

@glbrntt glbrntt enabled auto-merge (squash) May 2, 2025 07:08
@glbrntt glbrntt merged commit 0d850d6 into grpc:main May 2, 2025
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🆕 semver/minor Adds new public API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants