Gateway API validations too strict for redirect status codes

[JackStromberg]

What happened:
Gateway API has validations that only account for 301 and 302 HTTP Redirects.

gateway-api/apis/v1/httproute_types.go

Line 1069 in 1edf7e9

// +kubebuilder:validation:Enum=301;302

What you expected to happen:
RFC 2616 defines several other redirects, including: 303, 304, 305, and 307.

Anything else we need to know?:
Ask would be to align enum validations to RFC2616 section 10.3

Thank you!

[youngnick]

It seems very reasonable to me to ensure that all the valid redirect codes can be used in this enum.

But it does raise the question of whether we should be testing the behavior for each redirect code? Currently we are only testing 301 in the conformance tests.

[shaneutt]

It seems very reasonable to me to ensure that all the valid redirect codes can be used in this enum.

+1

But it does raise the question of whether we should be testing the behavior for each redirect code? Currently we are only testing 301 in the conformance tests.

Yes, it does seem like some simple conformance tests around this would be ideal to help reduce implementations being caught off-guard by requirements.

[WojciechLuczkow-Flyr]

Hello, There is actually issue linked with that:
In postman, by default, 301 and 302 redirect change request method to GET (unless configured to not do it).
According to Mozilla docs:
In order to ensure guarantees that the method and the body will not be changed when the redirected request is made:
307 or 308 should be used for redirect.

[danehans]

But it does raise the question of whether we should be testing the behavior for each redirect code? Currently we are only testing 301 in the conformance tests.

+1 on having conformance test coverage for the additional status codes.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[JackStromberg]

/remove-lifecycle stale

To loop back around, is it acceptable to follow RFC; outstanding action being additional conformance test coverage for addition of those status codes?

[robscott]

/remove-lifecycle stale

To loop back around, is it acceptable to follow RFC; outstanding action being additional conformance test coverage for addition of those status codes?

Thanks for the follow up on this. Since this is relatively small in scope, I don't think we'd really need a GEP for this, but I'd love to see it get into v1.2.

[robscott]

Given all the supportive comments above, I think we can mark this as accepted.

/triage accepted

[robscott]

@JackStromberg do you have time to work on this?

[divarvel]

RFC2616 is quite outdated, so the status list from the original post is incomplete.

RFC9110 adds the 308 response code as well https://httpwg.org/specs/rfc9110.html#status.308