GEP 1767: CORS Filter

[lianglli]

What type of PR is this?
/kind gep

What this PR does / why we need it:
This GEP proposes to add a new field HTTPCORSFilter to HTTPRouteFilter.

Which issue(s) this PR fixes:
Fixes #1767

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

Hi @lianglli. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[youngnick]

Thanks for the energy here @liangli, but the correct process here is for you to add some discussion about this feature to the proposed set of Experimental changes in #3403, and then, if this CORS GEP is selected for an Experimental slot by the community's voting, this PR will be able to move forward.

This is a useful feature that already has a GEP, has been discussed before, and is not too big, so it's reasonably likely that it will be included if we can free up enough Experimental slots by moving things to Standard.

I note that you added this to the 1.2 Experimental discussion as well, so it's fine to just reuse the same description in the v1.3 scoping discussion there so that any new folks will have the context to vote.

Until then, sadly, this PR will need to be on hold.

/hold

[robscott]

Thanks for writing up this GEP @lianglli! This made the cut for v1.3 release scoping, it's great to already have a GEP PR ready for review, will take a look shortly.

/ok-to-test

[robscott]

Thanks for all your work on this @lianglli! This is incredibly detailed and well written. I took a first pass and left some initial comments.

/cc @strongjz @howardjohn @youngnick

[robscott]

What happens if a user has configured * here? Should the Gateway implementation reject the request? Or do we just need to add CEL validation to prevent allowCredentials being set to true at the same time as this is set to *?

[howardjohn]

I think you may be mixing up the user HTTPRoute config and the server's expected response. a user can legitimately set * in the config certainly -- this seems to be saying they cannot set it in the response header.

However, I am not sure why? The spec does not seem to reject *? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers#syntax

[strongjz]

We had someone in ingress-nginx, request that we updated CORS to accept * and null

kubernetes/ingress-nginx#12402

[spacewander]

Note that Envoy can't return * directly because it treats * specially:
https://github.com/envoyproxy/envoy/blob/6445d0dcdd33413e47454221fa80b3cfabea7d4e/source/extensions/filters/http/cors/cors_filter.cc#L159-L163.

[lianglli]

What happens if a user has configured * here? Should the Gateway implementation reject the request? Or do we just need to add CEL validation to prevent allowCredentials being set to true at the same time as this is set to *?

When responding to a credentialed requests, the response headers Access-Control-Allow-Origin, Access-Control-Expose-Headers, Access-Control-Allow-Methods and Access-Control-Allow-Headers can NOT use * as value.

However, if a HTTPCORSFilter sets AllowCredentials as true and configures * for AllowHeaders, the gateway will return HTTP response header Access-Control-Allow-Credentials: true and Access-Control-Allow-Headers: * to the "preflight" request based on the HTTPCORSFilter specifically.

Then, clients will NOT be able to send actual cross-origin request.

[lianglli]

Note that Envoy can't return * directly because it treats * specially: https://github.com/envoyproxy/envoy/blob/6445d0dcdd33413e47454221fa80b3cfabea7d4e/source/extensions/filters/http/cors/cors_filter.cc#L159-L163.

Most gateways support the * wildcard as the value of a HTTP header.
Moreover, * wildcard is a valid character of header value based on rfc7230.

Hence, the envoy should support it in future.

[youngnick]

This field (and this spec in general) is pretty unclear as to which "user" we're talking about.

I suggest using different names for the HTTPRoute owner (maybe "user" is okay here), and the client, (should probably use that word instead).

So, I think what @robscott was saying is "What happens if the HTTPRoute owner has configured * here?"

The text says:

    // When responding to a credentialed requests, the gateway must specify 
    // one or more HTTP headers in the value of the Access-Control-Allow-Headers response header, 
    // instead of specifying the * wildcard.

What headers should the implementation respond with? Below, @spacewander suggests responding with whatever was sent in the Access-Control-Request-Headers field in the OPTIONS request. Whatever we want to do MUST be defined in this field, as what to do in the other cases:

• * is configured in this field, and Access-Control-Request-Headers is not sent
• One or more values are configured in this field and Access-Control-Request-Headers is sent
• One or more values are configured in this field and Access-Control-Request-Headers is not sent

What we are aiming for is that someone who reads the spec should be able to understand enough to write conformance tests for the spec, ideally without looking at any other documents.

[lianglli]

    // A wildcard indicates that the requests with all HTTP headers are allowed.
    // The Access-Control-Allow-Headers response header can only use `*` wildcard 
    // as value when the field AllowCredentials is unspecified.
    //
    // Input:
    //   Access-Control-Request-Headers: Content-Type, Cache-Control
    //
    // Config:
    //   allowHeaders: ["*"]
    //
    // Output:
    //   Access-Control-Allow-Headers: *
    //
    // When the field AllowCredentials is specified, the gateway must specify 
    // one or more HTTP headers in the value of the Access-Control-Allow-Headers 
    // response header, instead of specifying the `*` wildcard. The value of the 
    // header Access-Control-Allow-Headers same as the Access-Control-Request-Headers 
    // header provided by the client.
    //
    // Input:
    //   Access-Control-Request-Headers: Content-Type, Cache-Control
    //
    // Config:
    //   allowHeaders: ["*"]
    //   allowCredentials: true
    //
    // Output:
    //   Access-Control-Allow-Headers: Content-Type, Cache-Control 
    //   Access-Control-Allow-Credentials: true

[lianglli]

• One or more values are configured in this field and Access-Control-Request-Headers is sent
• One or more values are configured in this field and Access-Control-Request-Headers is not sent

    // Multiple header names in the value of the Access-Control-Allow-Headers 
    // response header are separated by a comma (",").
    //
    // Config:
    //   allowHeaders: ["DNT", "Keep-Alive", "User-Agent", "X-Requested-With", "If-Modified-Since", "Cache-Control", "Content-Type", "Range", "Authorization"]
    //
    // Output:
    //   Access-Control-Allow-Headers: DNT, Keep-Alive, User-Agent, X-Requested-With, If-Modified-Since, Cache-Control, Content-Type, Range, Authorization

If one or more values are configured in this field AllowHeaders, the gateway always return response header 'Access-Control-Allow-Headers: $allowHeaders' , regardless of whether the request includes the header Access-Control-Request-Headers.

[robscott]

Why have a default here at all? This seems like it could be surprising to users unless it's common for implementations to have a default.

[lianglli]

Based on Fetch Living Standard, the default value of Access-Control-Max-Age is 5 (seconds).

If a HTTPCORSFilter does NOT set 'MaxAge' specifically, the gateway will return the header "Access-Control-Max-Age: 5" to clients by default.

For example, the default value of Access-Control-Max-Age for Ingress-NGINX Enable CORS is 1728000 seconds.

[howardjohn]

The question I have: if unset, should the server respond Access-Control-Max-Age: 5, or should the server not include anything and let the client decide (where it will likely default to 5s)?

Envoy prior art is "not include"

[mlavacca]

Since the default value for MDN is 5 seconds, I think it's good to set an explicit default here: in case the gateway does not include such a header, it's up to the client such a decision, which is never a good thing in my opinion. Setting a default here makes the whole thing explicit and always defined.

[howardjohn]

If the default is 'unset', we support all cases: if a user wants it to be unset (and let client decide) they can, and if a user wants it set they can explicitly set it.

Not sure how valid this is though

[howardjohn]

Thanks for the GEP -- top notch details!

[howardjohn]

I think you may be mixing up the user HTTPRoute config and the server's expected response. a user can legitimately set * in the config certainly -- this seems to be saying they cannot set it in the response header.

However, I am not sure why? The spec does not seem to reject *? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers#syntax

[howardjohn]

The question I have: if unset, should the server respond Access-Control-Max-Age: 5, or should the server not include anything and let the client decide (where it will likely default to 5s)?

Envoy prior art is "not include"

[spacewander]

Note that Envoy can't return * directly because it treats * specially:
https://github.com/envoyproxy/envoy/blob/6445d0dcdd33413e47454221fa80b3cfabea7d4e/source/extensions/filters/http/cors/cors_filter.cc#L159-L163.

[mlavacca]

Since the default value for MDN is 5 seconds, I think it's good to set an explicit default here: in case the gateway does not include such a header, it's up to the client such a decision, which is never a good thing in my opinion. Setting a default here makes the whole thing explicit and always defined.

[robscott]

Thanks for all the work on this @lianglli!

/lgtm
/approve
/release-note-none

Although I reopened a couple comment threads that I think could use a bit more discussion, they're clearly small enough to cover when we get into the next phase of the enhancement process with additions to API types.

[htuch]

Here and next paragraph, I think the Access-Control-Allow-Headers and Access-Control-Allow_methods headers are mixed up.

[mlavacca]

Thanks for the work on this, @lianglli!

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lianglli, mlavacca, robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mlavacca,robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[robscott]

Thanks for all the work on this @lianglli!

I'll hold off on merging this until the most recent comment has been resolved, but IMO this is sufficiently close to keep it in the v1.3 milestone and on to the next phase.