-
Hi, I've got a few questions about the HTTPRequestRedirectFilter behavior. I wonder if there are some guidelines around that behavior. (1) . . .
rules:
- filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
backendRefs:
- name: example-svc
weight: 1
port: 80 where one backendRef is configured. However, since the redirect is not conditional, the data plane will never proxy to the backend -- it will always redirect. That brings a few questions: (a) Should a Gateway implementation report to the user that the backendRefs will be ignored? (b) Considering that a Gateway implementation will ignore the backendRefs, should it validate the backendRefs? For example, insure that the backend service exists? Or can a Gateway implementation skip the validation of ignored backendRefs? (c) Is it necessary to have the backendRefs? Would it make sense to remove them from the example? (2)
(from https://github.com/kubernetes-sigs/gateway-api/blob/v0.5.0/apis/v1beta1/httproute_types.go#L829-L831) (a) If a Gateway implementation finds that a field is invalid in an HTTPRequestRedirectFilter and it sets Attached Condition for the Route to (b) What status code the data plane shall return? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Maybe, as a quality of implementation feature. I don't think the spec needs to require this though.
Yes, as a matter of principal, everything should be validated.
Not AFAICT.
Probably.
My opinion is that you should drop the route. Anything less than that is hard to understand and liable to have unexpected results.
If the gateway drops the route, probably serving a 503 on that route is the best option. |
Beta Was this translation helpful? Give feedback.
Maybe, as a quality of implementation feature. I don't think the spec needs to require this though.
Yes, as a matter of principal, everything should be validated.
Not AFAICT.
Probably.