Add support for adding / removing headers at the Ingress, namespace, and default level
I'm interested in implementing ingress level support. Is this annotation format acceptable?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: example
annotations:
contour.heptio.com/response-headers-to-add: |
Strict-Transport-Security "max-age=31536000; includeSubDomains"
Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
contour.heptio.com/response-headers-to-remove: |
X-Powered-By
spec:
...
Thanks for offering to work on this. My initial reaction to the annotation syntax is it’s pretty ugly, yaml embedded in annotations is quite verbose and not something people are going to get right first time.
One way around this might be to encode the header name in the annotation key, ie
contour.heptio.com/add-header-max-age: “...”
Where add-header- is a known prefix and there is a form for converting the suffix into a http header. This should work as http headers are not case sensitive.
The other question is should this be per ingress or per route. I can see an argument for per route.
On 9 May 2018, at 09:19, David Robinson notifications@github.com wrote:
I'm interested in implementing ingress level support. Is this annotation format acceptable?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: example
annotations:
contour.heptio.com/response-headers-to-add: |
Strict-Transport-Security "max-age=31536000; includeSubDomains"
Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
contour.heptio.com/response-headers-to-remove: |
X-Powered-By
spec:
...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Encoding the header in the annotation will do, I have no preference.
Headers are appended to requests/responses in a specific order, so we may be able to do both ingress and route. I'll experiment and see how it could work.
One other question, I assume we only care about response headers? I don't have any use-cases for adding headers to requests.
I see the need for this, but tbh I’m turned off by how ugly this will be to fit into the ingress object.
On 10 May 2018, at 06:38, David Robinson notifications@github.com wrote:
Encoding the header in the annotation will do, I have no preference.
Headers are appended to requests/responses in a specific order, so we may be able to do both ingress and route. I'll experiment and see how it could work.
One other question, I assume we only care about response headers? I don't have any use-cases for adding headers to requests.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
@davecheney, can you please provide some guidance regarding the annotation format? Unless I'm mistaken, the format I used in https://github.com/heptio/contour/pull/408 is the format you suggested.
If you're using contour for TLS termination x-forwarded-proto is needed in many cases -- couldn't find a way to set that.
+1 on wanting to see this happen. Right now I have a need to customize the Host header for route when proxying a request.
Here's a design I'm thinking of
spec:
routes:
prefix: /foo
headers:
add:
- name: "x-request-id"
value: "fixed value"
- name: "x-something"
value: "another fixed value"
remove:
- name: "Date"
- name: "ETag"
+1 for this: my use-case would require to add headers for requests. I would like to "mesh" Contour with Linkerd2, but it requires an extra header to be set, something like this:
l5d-dst-override: $service_name.$namespace.svc.cluster.local:80
Without this feature the ingress can't be part of the service-mesh, and can't take advantage of the mTLS feature provided by Linkerd2.
Hear hear. Would love to be able to add Contour to the list of Linkerd ingresses here: https://linkerd.io/2/tasks/using-ingress/
@davecheney would love to help work on this.
I see some work done for the Ingress object according to your initial suggestion in #408 and a sample provided for IngressRoute. Can we finalise the desired configuration format at this point so that we can implement this?
I'd argue that support for mimicking the relevant envoy api should exist in both IngressRoute and Ingress (possibly limited compared to IngressRoute)
Here's a design I'm thinking of
spec: routes: prefix: /foo headers: add: - name: "x-request-id" value: "fixed value" - name: "x-something" value: "another fixed value" remove: - name: "Date" - name: "ETag"
It's not clear whether this adds/removes headers from requests or responses. Both should be supported imho. Request headers need to be added for the Linkerd use-case, and response headers added for HSTS.
Most helpful comment
If you're using contour for TLS termination x-forwarded-proto is needed in many cases -- couldn't find a way to set that.