Add support for headers in action return

[andrew-s]

Proposed changes

This PR adds support for headers in the action return object. This closes/fixes #2420

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Notes

I've added in unit tests, but it looks like there are other tests within the repo - I have also validated by compiling and running on a local cluster.

[netlify]

👷 Deploy request for nginx-kubernetes-ingress pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	8d91886

[ADubhlaoich]

LGTM docs-wise but the majority of the PR is code, so I will not approve.

[andrew-s]

I think to be self critical of this PR;

What is done;

• Code for the controller and chart are implemented (I tested this, loaded the built alpine image into a kind cluster, with the chart and was able to test different variances on the action.return type, including without the headers)
• Docs match for action return

What is not done;

• Tests are mostly missing, the unit tests can't check if the headers have actually been set - I've noticed this for the errorpage action return headers too. Perhaps the other tests that run from the data folder would be better suited?

[andrew-s]

I've updated the PR to passing unit tests

[andrew-s]

@ADubhlaoich @haywoodsh

I think this needs someone from nginx to weigh in. With the PR as it is now, the generated/expected spec isn't correct - it would generate errorPages as;

                              headers:
                                allOf:
                                - items:
                                    description: Header defines an HTTP Header.
                                    properties:
                                      name:
                                        type: string
                                      value:
                                        type: string
                                    type: object
                                - items:
                                    description: Header defines an HTTP Header.
                                    properties:
                                      name:
                                        type: string
                                      value:
                                        type: string
                                    type: object
                                type: array

This is because ErrorPageReturn uses ActionReturn which now has headers, so this applies headers twice. There's two solutions;

• ErrorPageReturn exclusively uses ActionReturn which now has headers, this would need all of the tests updating and anywhere that uses headers on ErrorPageReturn directly to then implement headers onto ActionReturn within the struct
• ErrorPageReturn no longer uses ActionReturn and implements Code, Type and Body directly - all of the tests and other logic which uses ActionReturn on ErrorPageReturn to then use these fields.

After some initial testing, these struct changes to produce the expected results.

I think these changes could break any existing PRs but vice versa, if we decide one of these routes then it would make sense to try and merge quickly to prevent conflicts.

[haywoodsh]

Just trying to make it clearer, in the current API,ActionReturn has 3 fields, Code, Type and Body, and ErrorPage has 4 fields:Code, Type, Body and Headers, as it uses ActionReturn and Headers. After this PR, both Action.Return and ErrorPage.Return will have the same items.

I like the first solution more, because I don't think Action.Return and ErrorPage.Return will divert again in the future, like something should only exist for Action but not ErrorPage, or the other way around.

Also, I saw ErrorPageRidirect also has only one item ActionRedirect.

type ErrorPageRedirect struct {
	ActionRedirect `json:",inline"`
}

Therefore, I feel we should be consistent and remove Headers from ErrorPageReturn in this line, so that it becomes:

type ErrorPageReturn struct {
	ActionReturn `json:",inline"`
}

As we are not changing the API for ErrorPage.Return, we might only need some minor refactorings to the unit tests from what I can when I tested it locally.

[andrew-s]

That makes the most sense, I've made the change, updated tests and generated the new config.

[vepatel]

the unit tests can't check if the headers have actually been set

@haywoodsh @andrew-s I think we can add some assertions in following tests:

• https://github.com/andrew-s/kubernetes-ingress/blob/feature/action-return-headers/tests/suite/test_virtual_server_canned_responses.py (data source)
• https://github.com/andrew-s/kubernetes-ingress/blob/feature/action-return-headers/tests/suite/test_v_s_route_canned_responses.py (data source)

[andrew-s]

@haywoodsh @vepatel Added the suite tests, this should cover the three scenarios for both virtualserver and virtualserverroute;

• Invalid OpenAPI test
• Valid header and contents
• Update of header and contents

[jjngx]

🚀

[haywoodsh]

Thank you for your contribution @andrew-s!