Header and Host Rewrite with Contour 1.1
Jan 16, 2020
Contour continues to take shape with new features. Our latest release, Contour 1.1, now includes request and response header manipulation as well as host rewriting to external domains. Contour 1.1 also lets you specify a service’s protocol in HTTPProxy and adds back prefix rewrite support, which was the last feature blocking many users from migrating from IngressRoute to HTTPProxy.
Manipulating request and response headers are supported per-Service or per-Route. A
HeaderRequestPolicy can be defined for both request and response requests.
The header request policy has the following configuration:
- Set: Takes a name-value pair and will create a header if it does not exist or update the value of the header specified by the key
- Remove: Takes the name of a header to remove
The following example takes requests from
headers.projectcontour.io/ and applies the following logic:
- Adds the header
X-Foo: barto any request before it is proxied to the Kubernetes service named
s1and removes the header
- After the request is processed by service
s1, the response back to the requester will have the header
X-Service-Name: s1added and will remove the header
- name: s1
- name: X-Foo
- name: X-Service-Name
Prefix Rewrite Support
Path prefix rewrite was a feature in IngressRoute that got removed right before Contour 1.0 was released. Now in Contour 1.1, HTTPProxy supports rewriting the HTTP request URL path prior to delivering the request to the backend service. Rewriting, which is performed after a routing decision has been made, never changes the request destination.
The pathRewritePolicy field specifies how the path prefix should be rewritten. The replacePrefix rewrite policy specifies a replacement string for a HTTP request path prefix match. When this field is present, the path prefix that the request matched is replaced by the text specified in the replacement field. If the HTTP request path is longer than the matched prefix, the remainder of the path is unchanged.
The following example will replace the prefix
/app/api/v1 on the request:
- name: s1
- prefix: /v1/api
For more information, see the documentation on
Contour supports routing traffic to
ExternalName service types. This kind of traffic routing allows users to proxy traffic to resources that aren’t running in the same Kubernetes cluster. You could, for example, proxy traffic to an external object storage bucket.
Some users encountered a problem with this feature, in that the host header that the externalName service received was the same host header as in the original request. This problem potentially leads to routing in the external name service to fail.
To solve this issue, you can set a
requestHeadersPolicy and define the
Host header to match the value of the externalName; here’s an example:
- name: s1
- name: Host
Now requests to
header.projectcontour.io will proxy to
external.dev with the header
Since the release of Contour 1.0,
HTTPProxy became the successor of
IngressRoute going forward. One struggle for users wanting to migrate is a way to convert IngressRoute resources to HTTPProxy resources.
A new tool named
ir2proxy will take an
IngressRoute object and migrate it to an HTTPProxy.
$ ir2proxy basic.ingressroute.yaml
- prefix: /
- name: s1
The Contour team would love to hear your feedback! Many of the features in this release were driven by users who needed a better way to solve their problems. We’re working hard to add features to Contour, especially in expanding how we approach routing.
If you are interested in contributing, a great place to start is to comment on one of the issues labeled with Help Wanted and work with the team on how to resolve them.
We’re immensely grateful for all the community contributions that help make Contour even better! For version 1.1, special thanks go out to the following people:
This blog post covers key features of the Contour v0.15 release including leader election and the Contour configuration file.
This blog post covers key features of the Contour v0.14.0 release including securing xDS communication with Envoy.
The Journey from 0.1 to 1.0