-
Notifications
You must be signed in to change notification settings - Fork 423
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
Service Discovery: allow configuration to replace URI scheme for HTTP calls #381
Comments
Why? What's the scenario? |
App having code pointing at "http://something" and wanting to have that resolve to "https://something" before the request is actually made, so that e.g. redirect responses don't have to be followed, etc. |
But why? When does this happen in practice and why would we do that? What did we run into? |
PS: If we do anything like this it needs telemetry. Transformations like this make debugging HARD. |
How would you express this in the app model? |
When we hit the issue with the forwarder following redirects I wondered why we couldn't have service discovery just map it on the way out, and we had the questions RE specifying http vs. https in app code. Would definitely be interesting to see if anything like this is done in other stacks. |
I'm not a fan of this, it feels like magic that would be hard to explain. |
How do you handle custom ports? |
The |
Last discussion on this produced the idea of an explicit scheme that would need to be specified in the address for service discovery to perform this action, e.g. "svc://basketservice". The "svc" would be replaced by "http" or "https" based on service discovery configuration/behavior. The hope would be this feature could help us solve the current usability issues that forced us to use "http" everywhere in our templates, etc. |
We don't see this for P3 cutoff |
@ReubenBond we want to get something here for preview4 |
@davidfowl I thought you were against this idea? Let's discuss it |
I am against the idea if the scheme was specified. If the scheme is |
Someone suggested |
We have to do in P5 |
This is done now thanks to #2719 yeah @ReubenBond? |
Yes, we can close this |
eg, replace "http://." with "https://."Latest proposal was to support something like "svc://" that would be replaced with "http://" or "https://" based on service discovery configuration.
The text was updated successfully, but these errors were encountered: