-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Closed
Labels
area/networkingkind/featureWell-understood/specified features, ready for coding.Well-understood/specified features, ready for coding.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.Indicates that an issue or PR should not be auto-closed due to staleness.triage/acceptedIssues which should be fixed (post-triage)Issues which should be fixed (post-triage)
Milestone
Description
Github issue for KIngress Host Rewrite Support proposal
Description
KIngress should support host rewriting. This would allow (after further work to expose some user-facing chrome) nice use cases such as:
- Vanity URLs: backing one’s “vanityismy.name” domain with a knative service. Today this would require custom work in Istio/Envoy/Contour etc depending on which underlying network implementation is being used, making any solution non-portable between Knative implementations (see Support Vanity Domains #1185).
- Splitting traffic between KServices, for example the current documented way to do this (see https://knative.dev/docs/serving/samples/knative-routing-go/index.html) requires custom work with an Istio VirtualService, and is therefore non-portable between different Knative deployments.
- Stable URLs for Eventing targets (Support putting infrastrucure outside of user's namespace eventing#2718). Allow giving a stable name to an Addressable (which would itself be Addressable).
Scope
This feature is just for the internal KIngress work, a separate feature and proposal will address user-facing chrome for this.
Some Related Issues
Support Vanity Domains: #1185
Allow for a per Service URL to be specified: #3687
Support putting infrastructure outside of user’s namespace: knative/eventing#2718
RFC: Towards more sophisticated domain mappings: #2985
Feature Proposal Document
Further details in the Feature Proposal Document
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area/networkingkind/featureWell-understood/specified features, ready for coding.Well-understood/specified features, ready for coding.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.Indicates that an issue or PR should not be auto-closed due to staleness.triage/acceptedIssues which should be fixed (post-triage)Issues which should be fixed (post-triage)