- Notifications
You must be signed in to change notification settings - Fork38
feat(destination): Add destination profile protocol#443
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Currently, we only have a way of specifying if a destination is opaque and not any other protocol.This adds a new `protocol` field (superceding `opaque_protocol`) that lets the destination controller set the protocol a destination expects.Signed-off-by: Scott Fleener <scott@buoyant.io>
| enum Protocol { | ||
| // An unknown protocol was set by the user. | ||
| UNKNOWN = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is the important part of this change, and also the one I'm not 100% sure about.
It may make sense to combine the UNKNOWN and OPAQUE cases, since we'd expect the proxy to treat it the same in both cases.
I'm also not sure if we need an explicit DETECT case. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'd argue that if any should be combined, it should be UNKNOWN and DETECT. if the protocol is UNKNOWN, I would expect the proxy to do protocol detection whereas if the protocol is OPAQUE, I would expect the proxy to skip protocol detection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The reasoning here is that if the protocol is UNKNOWN, that means the user has set a protocol, it's just one we don't recognize. IMO treating it as opaque seems the most appropriate here.
Currently, we only have a way of specifying if a destination is opaque and not any other protocol.
This adds a new
protocolfield (supercedingopaque_protocol) that lets the destination controller set the protocol a destination expects.