Skip to content

Gateway API validations too strict for redirect status codes #2748

Open
@JackStromberg

Description

@JackStromberg
Contributor

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

// +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!

Activity

youngnick

youngnick commented on Jan 30, 2024

@youngnick
Contributor

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

shaneutt commented on Jan 30, 2024

@shaneutt
Member

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

WojciechLuczkow-Flyr commented on Mar 5, 2024

@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

danehans commented on Mar 5, 2024

@danehans
Contributor

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

k8s-triage-robot commented on Jun 3, 2024

@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

added
lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
on Jun 3, 2024
JackStromberg

JackStromberg commented on Jun 3, 2024

@JackStromberg
ContributorAuthor

/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?

removed
lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.
on Jun 3, 2024
robscott

robscott commented on Jun 3, 2024

@robscott
Member

/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

robscott commented on Jun 3, 2024

@robscott
Member

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

/triage accepted

robscott

robscott commented on Jun 3, 2024

@robscott
Member

@JackStromberg do you have time to work on this?

divarvel

divarvel commented on Oct 14, 2024

@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

linked a pull request that will close this issue on May 29, 2025
danehans

danehans commented on Jun 6, 2025

@danehans
Contributor

@robscott if this is not considered a bug, can you remove the applicable label (xref)?

robscott

robscott commented on Jun 6, 2025

@robscott
Member

/remove-kind bug
/kind feature

added
kind/featureCategorizes issue or PR as related to a new feature.
and removed
kind/bugCategorizes issue or PR as related to a bug.
on Jun 6, 2025
JackStromberg

JackStromberg commented on Jun 6, 2025

@JackStromberg
ContributorAuthor

fyi -- looks like this is being worked on. Thank you @davidwin93!

Cross referencing: #3823

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.triage/acceptedIndicates an issue or PR is ready to be actively worked on.triage/needs-informationIndicates an issue needs more information in order to work on it.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @divarvel@robscott@danehans@shaneutt@youngnick

      Issue actions

        Gateway API validations too strict for redirect status codes · Issue #2748 · kubernetes-sigs/gateway-api