Enhancement Proposal for Adding HTTP header to HAProxy Without Customizing haproxy.config Template

[miheer]

Enhancement Proposal for Adding HTTP header to HAProxy Without Customizing haproxy.config Template
https://issues.redhat.com/browse/NE-982

[Miciah]

What does this enhancement have to do with logging? What is "the router API"? I think you can just say that the enhancement extends the IngressController API and the Route API.

[miheer]

copy paste error from your logging enhancement. BTW it was not ready for review. So, sorry for that!

[Miciah]

The haproxy.config file is an implementation detail. Does the enhancement provide the ability to set HTTP request headers, HTTP response headers, or both?

[miheer]

I have asked this in the open questions. As per the RFE all the headers which customer need seem to response headers.

[Miciah]

Can you be more specific? Given the history of the RFE (in which various people have made requests about various HTTP headers) and the fact that you are modifying both the Route API and the IngressController API, I would expect multiple user stories.

[miheer]

done

[Miciah]

It is useful to specify whom you are enabling (cluster administrator or route owner). However, "set in the global section of the haproxy.config" and "set in the backend section default_backend openshift_default. of the haproxy.config" are implementation details (and I don't think the openshift_default backend is relevant for the implementation of the feature anyway). In this section, focus on the goal, not the implementation. What is the enhancement ultimately enabling the cluster admin or route owner to do?

[miheer]

done

[Miciah]

I don't understand what you are saying here. Are you saying that validating input is not a goal (key word: "proper")? Are you saying that admins and users will be able to specify names but not values (key word: "values")?

[miheer]

yes validating HTTP header name and value is not our goal.

[miheer]

done

[Miciah]

Fix the number agreement:

Suggested change

	The template translates these values into an appropriate `http-response set-header` stanzas.
	The template translates these values into the appropriate `http-response set-header` stanzas.

Beyond that, you're repeating a sentence that you used in another section. If you find yourself repeating some text, please either rework the text to avoid duplication or use signposting to improve the cohesion of the text. For example:

Suggested change

	The template translates these values into an appropriate `http-response set-header` stanzas.
	Similarly to the treatment of the `ROUTER_SET_HTTP_HEADERS` variable for global settings, the template translates the route-specific `RouteSetHTTPHeaders` values into the appropriate `http-response set-header` stanzas.

[miheer]

this is no longer applicable. As from route we don't encode values.

[Miciah]

Did you mean to put this text outside the block?

[miheer]

fixed

[Miciah]

Use a permalink, or delete the link if it isn't needed.

[miheer]

This has been changed.

[Miciah]

These dates need to be updated.

[Miciah]

This line needs to be updated or deleted.

[miheer]

done. Added TODO

[alebedev87]

I don't see how the headers can be set in the global section of the HAProxy config. http-request and http-response can only be set in frontend/listen/backend sections.

[alebedev87]

Fixed, the implementation details mention frontend section.

[miheer]

So, that is the reason we don't need add-header.

I don't understand. It looks like you just described what "set-header" and "add-header" do, but I don't see any explanation of why we don't need "add-header".

So, that is the reason we don't need add-header.

I don't understand. It looks like you just described what "set-header" and "add-header" do, but I don't see any explanation of why we don't need "add-header".

fixed it

[alebedev87]

Where exactly the headers specified on the ingresscontroller level should be set in HAproxy config? Will they be set on all the existing routes (backends in HAProxy config)?

[alebedev87]

What about the visibility for the user? Should these headers be added to the route's status or to the route's spec?

[miheer]

spec

[alebedev87]

I'm wondering how this feature will co-exist with the OpenShift's Ingress HSTS policy which also sets a header (STS header) on the routes.

[Miciah]

This is addressed by a comment in the RFE:

Create an “immutable” OpenShift deny-list of headers that are known in advance to be problematic (e.g. HSTS)

https://issues.redhat.com/browse/RFE-464?focusedCommentId=20064927&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20064927

[miheer]

@Miciah but won't it be a different epic ? Adding admission list will again need a API field.

[miheer]

In the router we can check the header for Strict-Transport-Security: in the route and then ignore it.

[Miciah]

Why would it be a different epic?

Going back to the comment I cited:

Create an “immutable” OpenShift deny-list of headers that are known in advance to be problematic (e.g. HSTS)

We don't need an API field for the immutable deny-list, which would include strict-transport-security.

The comment I cited also mentions the following:

Cluster Admins can delegate per-route controls (perhaps with an allow-list, or an attribute in the global ones above) to, for example, Project Admins

We would need a field in the IngressController API for that. If there's a reason this should be a separate epic, please give an argument. We can discuss it with PM if it really should be out of scope.

[alebedev87]

I see, so the immutable deny list will exist in the code and will be documented. It'll include HSTS (as managed by the route's annotation) and potentially some other headers.

[miheer]

validation details added.

[Miciah]

Thanks! I mostly like the direction the API is going in, and the goals and non-goals are more complete. I still have some questions, and some of my earlier comments still need to be addressed.

[Miciah]

Suggested change

	1. As a cluster administrator, I need to configure an IngressController to set/append certain response HTTP headers which are:
	1. As a cluster administrator, I need to configure an IngressController to set/append certain HTTP response headers, such as the following:

[Miciah]

What syntax is this? I would expect either prose with a bulleted list or an excerpt of a syntactically valid HTTP response.

Why is "Strict-Transport-Security" in this example? In another comment thread, we are discussing a built-in deny-list, which would include this particular header (i.e. we would prohibit the cluster admin from specifying this header), so it seems to me like a bad example to use here.

[miheer]

we were not sure if deny list shall be added at that time

[Miciah]

Even if we didn't add the deny list, it would be better not to provide an example of something we would have denied. * grin *.

[Miciah]

User stories should focus on the user perspective; "frontend fe_no_sni, frontend public, frontend fe_sni" are implementation details.

[miheer]

changed

[Miciah]

You need to say whether the goals include customizing request or response headers. For now, you can go with "response headers" while you discuss the requirements with PM and other stakeholders.

Suggested change

	1. Enable the cluster administrator to specify HTTP headers in the IngressController CR Spec that should get set/append at the global
	level for all backends which is not application specific.
	1. Enable the cluster administrator to specify HTTP response headers in the IngressController CR spec that should get set or appended at the global
	level, i.e. for all routes.

[miheer]

changed

[Miciah]

What do you mean by "for sending to application's backends only"? This phrase makes it seem as if the goal were to allow customizing request headers (which get sent to the backend) and not to allow customizing response headers (which get sent back to to the client). I thought we definitely wanted to allow customizing response headers (such as the ones in your examples: x-xss-protection, x-content-type-options, and x-frame-options), and you have an open question about customizing request headers.

Suggested change

	2. Enable the developer or user to specify HTTP headers in the Route Spec of Route(which is not a passthrough route) for their application
	that should get set/append for sending to application's backends only.
	2. Enable the route owner to specify HTTP response headers in the Route spec (when it is not a passthrough Route) for their application
	that should get set or appended when forwarding a response to the client.

[miheer]

fixed

[Miciah]

Raise this with PM, and ask stakeholders on the RFE. If no one has asked for it, we can assume for now that customizing request headers is a non-goal.

[miheer]

changed

[Miciah]

I think so:

delete Server & X-Powered-By

https://issues.redhat.com/browse/RFE-464?focusedCommentId=20025699&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20025699

We will allow global replace, delete and append options.

https://issues.redhat.com/browse/RFE-464?focusedCommentId=20064927&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20064927

Is there a good reason not to include a delete option?

For what it's worth, Gateway API has a delete option: https://github.com/kubernetes-sigs/gateway-api/blob/e7260d356a01afc973772610b6223686a971b43e/apis/v1beta1/httproute_types.go#L778-L798

[miheer]

changed

[Miciah]

This was mentioned on the RFE. If you have concerns about this, please explain those concerns here and raise them with PM.

[miheer]

There is no concern as such but it is like multiple feature requests combined in one epic.
I think will increase the number of points in the JIRA.

[Miciah]

Please describe in the EP what you mean by "admission list option" so that we can discuss it.

[miheer]

we are no longer creating an admission list. we have a immutable list of not allowed response headers

[Miciah]

I have no idea why we would set the balance algorithm based on an HTTP header. Where does this question come from? Is there a particular header you have in mind? Is this question related to some statement or comment in the RFE, or some request someone has conveyed to you?

[miheer]

Someone in the jira ticket was asking for it.
https://issues.redhat.com/browse/RFE-464?focusedCommentId=14180858&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14180858

[Miciah]

I see, the request is that if a route is annotated with haproxy.router.openshift.io/balance: hdr(x-foo), then OpenShift router should write balance hdr(x-foo) in haproxy.config. That's trivial to do, but it's orthogonal to customizing HTTP headers. I agree that it is out of scope for this enhancement and should be handled with a separate RFE.

[alebedev87]

Setting load balancing algorithm based on headers is already mentioned in the Non-goals. Doesn't need to be in the open question. As a matter of fact I think this doesn't need to be mentioned at all since:

1. We seem to go with the response only API while haproxy.router.openshift.io/balance: hdr()makes sense for the requests only.
2. Even if we'd have the request API too that would only be a helper for the haproxy.router.openshift.io/balance: hdr() annotation, not enabler or prerequisite.

[Miciah]

It makes sense to me to list it as a non-goal because someone asked for it on the RFE. I don't know why the person who asked for it thought a feature for customizing headers would include "balance traffic based on the header", but since someone did think that, we might as well state explicitly that the enhancement does not include it.

Anyway, I think we are all in agreement that this is a non-goal, so @miheer, please add some text below this question in the EP to say that the question has been resolved, and that we have decided that this is a non-goal for this EP.

[Miciah]

@miheer, reminder to add some text to the EP for this (and other) open questions. I'll also provide some examples in case that's helpful.

We have several DNS- and ingress-related EPs that present open questions (or questions that were previously open) in a Q&A style, such as the forward-dns-over-tls, cache-tuning, and lb-allowed-source-ranges EPs. The ip-interface-selection EP has a similar format, and the configurable-dns-loadbalancerservice EP similarly has an open question that has been "closed" with an explanation. We sometimes put open questions in the EP for follow-up, for example the route-subdomain EP. We sometimes write open questions with a note to document the issue, as in the haproxy-healthcheckinterval and tunable-router-kubelet-probes EPs. We also sometimes have an open question with a link to an issue tracker, as with the contour-operator EP. The console customize-add-page and customize-project-roles EPs do a really nice job of explaining the question with an example and quoting the decision that was made on the question (the only thing I would add would be a citation for the answer). The infrastructure-external-platform-type EP does a really nice job of listing open questions and "answered" questions with detailed answers and citations.

The purpose of writing down these open questions is to show some of the thought that went into the design so that people can read that these questions have been raised, discussed, and resolved (or possibly that they are still open questions that may warrant follow-up).

The next person who reads the EP cannot be expected to read through all the GitHub comments; it's your job to make sure that the EP itself has this information.

[miheer]

done

[Miciah]

In my opinion, we should prohibit specifying strict-transport-security using the new API, for the following reasons:

• HSTS is already configurable through a route annotation.
• We already have an API for restricting HSTS in the cluster config.
• The annotation value is already validated in the template (deads2k wrote an admission plugin, but we never merged it: UPSTREAM: <carry>: add validation for ingress.config.openshift.io component routes kubernetes#1216) and by an admission plugin (see Bug 1986408: NE-310 HSTS Route Admission Plugin openshift-apiserver#224).
• Adding a second way to configure HSTS would significantly complicate this enhancement.

[miheer]

Hi @Miciah ! we can restrict this header by putting a condition in the haproxy.template. WDYT ?
The other way will be adding a API field for the admission list of headers.
Yes apiserver code refers ingress config object and verifies the hts annotation set in the route.

The annotation value is already validated in the template (deads2k wrote an admission plugin, but we
never merged it: openshift/kubernetes#1216).

Which annotation ? I tried to search for hsts but did not find anything related to it in the commit.

[miheer]

openshift/kubernetes#1216 I think I can use it for verifying headers the ingress controller CR as per admission list I will set in the ingress config object.
For the verifying the headers mentioned in the route spec w.r.t to admission list mentioned in the ingress config we can follow the similar approach we for hsts.

[Miciah]

Hi @Miciah ! we can restrict this header by putting a condition in the haproxy.template. WDYT ?

No, we can do better than that; we can restrict it in route validation, or write a new admission plugin alongside the existing admission plugins.

The other way will be adding a API field for the admission list of headers.

Why would we add an API field? The list of prohibited headers is supposed to be an immutable list.

Yes apiserver code refers ingress config object and verifies the hts annotation set in the route.

Indeed, I found the correct link, and I have edited my earlier comment.

The annotation value is already validated in the template (deads2k wrote an admission plugin, but we
never merged it: openshift/kubernetes#1216).

Sorry, I mixed up PRs. That admission plugin for the annotation was merged: openshift/openshift-apiserver#224

Which annotation ? I tried to search for hsts but did not find anything related to it in the commit.

haproxy.router.openshift.io/hsts_header.

[Miciah]

After discussing this with someone from the API team, I understand that adding validation for spec.httpSetHeaders to the existing route validation code in library-go is the way to go. (The "admission list option" mentioned earlier in this EP might require an admission plugin though, depending on what you have in mind for that option.)

[miheer]

@Miciah

Why would we add an API field? The list of prohibited headers is supposed to be an immutable list.

I didn't get it regarding immutable lists. We will need the input of headers to be denied either from the route Spec or route Annotation right ?

[miheer]

i think I got it that we will be hard coding some headers in the library-go validation for routes.

[Miciah]

I didn't get it regarding immutable lists. We will need the input of headers to be denied either from the route Spec or route Annotation right ?

No, "immutable" means that the user cannot change it.

i think I got it that we will be hard coding some headers in the library-go validation for routes.

Right, it can be hard-coded somewhere, and library-go is a reasonable place for it.

[miheer]

done

[Miciah]

This sentence needs to be fixed.

[miheer]

done

[alebedev87]

Just some suggestions on Summary and Motivation chapters.

[alebedev87]

Suggested change

	This enhancement extends the IngressController API and Route API to allow the user to set(replace) or append
	HTTP Response headers in the haproxy.config file. Using the new API, users may specify a list of
	HTTP Response headers either via IngressController API or Route API that should be set(replace) or appended or deleted.
	Creates an immutable(hardcoded) list of HTTP Response headers which can't be set(replace) or appended or deleted.
	This enhancement extends the IngressController API and Route API to allow the user to set(replace), append or delete
	HTTP response headers. Using the new API, users may specify a list of
	HTTP response headers either via IngressController API or Route API that should be set(replaced), appended or deleted.
	Also, this enhancement creates an immutable(hard-coded) list of HTTP response headers which can't be set(replaced), appended or deleted.

[miheer]

done

[alebedev87]

Suggested change

	1. As a cluster administrator, I need to configure an IngressController to set(replace)/append certain HTTP Response headers which are:
	- X-XSS-Protection "1; mode=block"
	- X-Content-Type-Options "nosniff"
	- X-Frame-Options "SAMEORIGIN"
	in order to satisfy compliance requirements at global level to send them to all clients.
	2. As a user/devops/developer, I need to configure Route to set/append HTTP Response headers which need to which
	are mentioned above to send them to the client which has called the route.
	3. To satisfy this use-case, the cluster administrator can set the IngressController's Spec
	or the developer can set Router's `spec.httpDeleteHeaders` field to set(replace) or append the required headers.
	4. As a cluster administrator, I need to configure an IngressController to delete certain HTTP Response headers which are:
	- X-XSS-Protection
	- X-Content-Type-Options
	- X-Frame-Options
	in order to satisfy compliance requirements at global level to not to send them to all clients.
	5. As a user/devops/developer, I need to configure Route to delete HTTP Response headers which need to which
	are mentioned above for not sending them to the client which has called the route.
	6. To satisfy this use-case, the cluster administrator can set the IngressController's Spec
	or the developer can set the Router's Spec with `spec.httpDeleteHeaders` field to delete the required headers by
	mentioning the header names mentioned above.
	1. As a developer, I need to update IngressController and Route APIs to be be able to set/append/delete certain HTTP response headers.
	2. As a cluster administrator, I need to configure an IngressController to set/append/delete certain HTTP response headers in order to satisfy compliance requirements at global level to send/not to send them to the client has called any route from IngressController's domain.
	3. As a user, I need to configure Route to set/append/delete HTTP response headers to send/not send them to the client which has called the route.

I suppose that the implementation would need only 3 user stories: API change, the changes in the cluster-ingress-operator and router.

[Miciah]

Is there precedent for writing, "As a developer, I need to update ___ API" as a user story? User stories are usually focused on end-user roles, such as cluster admin or project admin.

I do like simplifying the user stories where possible and simplifying the list so that it enumerates one user story per list item. It is helpful to provide the solution to the user story though. When writing an EP, I put the user story as a heading or italicized statement followed by one or more paragraphs explaining how the EP addresses the user story.

The user story should indicate who the end-user is (e.g. "cluster admin"), what the end user is trying to achieve (e.g. "delete the x-server response header in responses to client requests") and why ("so that I can avoid exposing information about internal systems to potentially malicious external actors"). Then you can explain how the EP solves that user story ("The cluster admin can configure the IngressController as shown in the following example yaml").

[alebedev87]

Is there precedent for writing, "As a developer, I need to update ___ API" as a user story? User stories are usually focused on end-user roles, such as cluster admin or project admin.

I created such user stories myself, for technical debt for instance. I suppose it's in the interest of NetEdge engineer to define and implement the deny list. That's why I put Developer as the actor for the first user story.

The user story should indicate who the end-user is (e.g. "cluster admin"), what the end user is trying to achieve (e.g. "delete the x-server response header in responses to client requests") and why ("so that I can avoid exposing information about internal systems to potentially malicious external actors"). Then you can explain how the EP solves that user story ("The cluster admin can configure the IngressController as shown in the following example yaml").

Isn't the Workflow chapter for this purpose?

[Miciah]

Is there precedent for writing, "As a developer, I need to update ___ API" as a user story? User stories are usually focused on end-user roles, such as cluster admin or project admin.

I created such user stories myself, for technical debt for instance. I suppose it's in the interest of NetEdge engineer to define and implement the deny list. That's why I put Developer as the actor for the first user story.

I can see creating user stories in Jira for tech debt, and we sometimes note potential future follow-up work in the goals/non-goals, proposal, or implementation details/notes/constraints sections. However, I still believe that user stories in the enhancement should be focused on end users.

The user story should indicate who the end-user is (e.g. "cluster admin"), what the end user is trying to achieve (e.g. "delete the x-server response header in responses to client requests") and why ("so that I can avoid exposing information about internal systems to potentially malicious external actors"). Then you can explain how the EP solves that user story ("The cluster admin can configure the IngressController as shown in the following example yaml").

Isn't the Workflow chapter for this purpose?

I would use user stories for the high-level description of the problem ("As a ___, I want to ___, so that I can ___") and solution ("To accomplish ___, ___ can use the new ___ API/field/whatever as in the following example") and then document the detailed step-by-step procedure as a workflow.

[miheer]

done

[alebedev87]

Suggested change

	1. Enable the cluster administrator to specify HTTP response headers in the IngressController CR spec that should get set or appended at the global
	level, i.e. for all routes.
	2. Enable the route owner to specify HTTP response headers in the Route spec (when it is not a passthrough Route) for their application
	that should get set or appended when forwarding a response to the client.
	3. Enable the cluster administrator to delete the HTTP response headers via IngressController CR.
	4. Enable the developer to delete the HTTP response headers via RouteSpec.
	5. This EP will set an immutable/hardcoded deny list of headers not allowed to set/append or deleted.
	Eg- we should prohibit specifying strict-transport-security using the new API, for the following reasons:
	HSTS is already configurable through a route annotation.
	We already have an API for restricting HSTS in the cluster config.
	Adding a second way to configure HSTS would significantly complicate this enhancement.
	1. Enable the cluster administrator to specify HTTP response headers in the IngressController CR spec that should be set, appended or deleted at the global level, i.e. for all routes.
	2. Enable the user to specify HTTP response headers in the Route spec (when it is not a passthrough Route) for their application
	that should be set, appended or deleted when forwarding a response to the client.
	3. Define an immutable/hard-coded deny list of headers which are not allowed to be set, appended or deleted.
	Eg- we should prohibit specifying strict-transport-security using the new API, for the following reasons:
	HSTS is already configurable through a route annotation.
	We already have an API for restricting HSTS in the cluster config.
	Adding a second way to configure HSTS would significantly complicate this enhancement.

[miheer]

done

[alebedev87]

Some comments about the new API.

[alebedev87]

IngressControllerSpec already has a field named HTTPHeaders which provides some parameters to manipulate the headers like adding the unique ID header or adjusting the header name's case.
For the sake of the logical regrouping, did you consider IngressControllerSpec.HTTPHeaders as the parent for the new API field(s)?

[miheer]

// httpHeaders defines policy for HTTP headers.
//
// If this field is empty, the default values are used.
//
// +optional
HTTPHeaders *IngressControllerHTTPHeaders `json:"httpHeaders,omitempty"`

The goal of this seems to be different i.e to set policies. But we can add the new field under this. WDYT @Miciah ?

[Miciah]

Using IngressControllerHTTPHeaders makes sense to me. Can we do that and still keep the new IngressController API and the new Route API consistent?

[miheer]

@Miciah openshift/api#1364

[miheer]

done

[alebedev87]

I don't quite understand the purpose of the action field.
The API seems to be designed with the HAProxy config in mind: http-response set-header is supposed to be used for the set case and http-response del-header for the delete case. In which case the question of why Action is needed arises.
However if the API tries to be a little more generic then the delete action can also be added, simplifying the API (HTTPDeletHeaders nor needed anymore).

[miheer]

The Value field is mandatory for Set or Replace headers so we will need different API for delete headers as it not need a value field.

[alebedev87]

Yeah, I think you have the point about the Value field. It's probably better to be validated by the OpenAPI, this may be clearer for the end user.
However, what about the actions? How do you plan to use them in the cluster-ingress-operator or router?

[Miciah]

Consider using a discriminated union where IngressControllerHTTPHeaderAction would be the discriminator, "Delete" would be an empty union member, and "Set" would be union member with a "Value" field. "Replace" and "Append" could be expressed as separate union members or as a field of the "Set" union member.

[alebedev87]

I can see the delete as a union member:

// +union
type IngressControllerHTTPHeader struct {
  // +unionDiscriminator
  // +kubebuilder:validation:Required
  Action IngressControllerHTTPHeaderAction `json:"action,omitempty"`
  // +optional
  Set *IngressControllerSetHTTPHeader `json:"set,omitempty"`
  // +optional
  Delete *IngressControllerDeleteHTTPHeader `json:"delete,omitempty"`
}

apiVersion: operator.openshift.io/v1                                                                                                         
kind: IngressController
metadata:
  name: default
spec:
  httpHeaders:
    headerManipultation:
      response:
      - action: "Set"
        set:
          name: "X-Frame-Options"
          value: "DENY"
      - action: "Delete"
        delete:
          name: "X-Powered-By"

but I cannot quite understand how it can be an empty union member.
Does it mean that only Delete action will be specified?

[alebedev87]

Thanks @Miciah for clarifying.
I'm almost fine with the discriminated union approach. It just feels a little verbose, especially on this part:

- action: "Set"
  name: "X-Frame-Options"
  set:  <-- this part
    value: "DENY"

[Miciah]

I'm almost fine with the discriminated union approach. It just feels a little verbose

True, but it's a standard pattern and makes it clear which fields apply to which action.

[alebedev87]

Sorry to bring this back but I don't think I'm 100% convinced that the discriminated union approach is better than the dedicated Set and Delete fields:

apiVersion: operator.openshift.io/v1                                                                                                         
kind: IngressController
metadata:
  name: default
spec:
  httpHeaders:
    headerManipultation:
      response:
        set:
        - name: "X-Frame-Options"
          value: "DENY"
        delete:
        - name: "X-Powered-By"

The API maybe a little less redundant for the discriminated union (Name field is common, no DeleteHeader type is needed) but is it more convenient to the end user? IMO it feels a little more verbose than the variant I showed above.
Btw don't we loose some validation using Name as an empty union member (same question)? it has to be optional while we need it required, no?

[alebedev87]

The discriminated union approach allows the API users to create an ordered list of the header manipulation instructions. This maybe more explicit expression of their intent as the dedicated set/delete fields approach would always raise the question in which order the two lists need to be translated into HAProxy configurations.

[Miciah]

Btw don't we loose some validation using Name as an empty union member (same question)? it has to be optional while we need it required, no?

For the record, I believe I answered the question here: #1296 (comment)

Name should not be a union member. You can use a inline field for the union type. See IngressControllerCaptureHTTPCookie (source) for an example.

Please let me know if that doesn't satisfactorily answer your question!

[alebedev87]

Similar to the question I asked about the IngressController API: what do you think about a field which regroup all the things which concern the headers? Similar to IngressControllerSpec.HTTPHeaders.

[miheer]

done

[alebedev87]

Same question as for the IngressController API.

[miheer]

changed

[alebedev87]

I think that the end user of the Route API is a different actor from the developer which designs the IngressController and Route APIs. The difference between them can be seen, for instance, in the part where the deny list is defined. The user actor cannot influence this list in any form, while the developer has to be define it.
Also what did you mean by the devops actor? How it's different from the user of the API?

[miheer]

I meant application developer

[alebedev87]

I see, then maybe this can be condensed. User/DevOps/Application Developer may simply become User.
Also I think that Developer as an actor representing NetworkEdge Engineer is still needed, for the deny list use case (user story and other mentions).

[miheer]

changed