Package io.fabric8.kubernetes.api.model.gatewayapi.v1

Class HTTPCORSFilter

  • All Implemented Interfaces:
    io.fabric8.kubernetes.api.builder.Editable<HTTPCORSFilterBuilder>, io.fabric8.kubernetes.api.model.KubernetesResource, Serializable
    @Generated("io.fabric8.kubernetes.schema.generator.model.ModelGenerator")
public class HTTPCORSFilter
extends Object
implements io.fabric8.kubernetes.api.builder.Editable<HTTPCORSFilterBuilder>, io.fabric8.kubernetes.api.model.KubernetesResource
    HTTPCORSFilter defines a filter that that configures Cross-Origin Request Sharing (CORS).
    See Also:
    Serialized Form

    • Constructor Detail

      • HTTPCORSFilter

        public HTTPCORSFilter()
        No args constructor for use in serialization

    • Method Detail

      • getAllowCredentials

        public Boolean getAllowCredentials()
        AllowCredentials indicates whether the actual cross-origin request allows to include credentials.


        When set to true, the gateway will include the `Access-Control-Allow-Credentials` response header with value true (case-sensitive).


        When set to false or omitted the gateway will omit the header `Access-Control-Allow-Credentials` entirely (this is the standard CORS behavior).


        Support: Extended

      • setAllowCredentials

        public void setAllowCredentials​(Boolean allowCredentials)
        AllowCredentials indicates whether the actual cross-origin request allows to include credentials.


        When set to true, the gateway will include the `Access-Control-Allow-Credentials` response header with value true (case-sensitive).


        When set to false or omitted the gateway will omit the header `Access-Control-Allow-Credentials` entirely (this is the standard CORS behavior).


        Support: Extended

      • getAllowHeaders

        public List<String> getAllowHeaders()
        AllowHeaders indicates which HTTP request headers are supported for accessing the requested resource.


        Header names are not case sensitive.


        Multiple header names in the value of the `Access-Control-Allow-Headers` response header are separated by a comma (",").


        When the `AllowHeaders` field is configured with one or more headers, the gateway must return the `Access-Control-Allow-Headers` response header which value is present in the `AllowHeaders` field.


        If any header name in the `Access-Control-Request-Headers` request header is not included in the list of header names specified by the response header `Access-Control-Allow-Headers`, it will present an error on the client side.


        If any header name in the `Access-Control-Allow-Headers` response header does not recognize by the client, it will also occur an error on the client side.


        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 `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowHeaders` field specified with the `*` wildcard, the gateway must specify one or more HTTP headers in the value of the `Access-Control-Allow-Headers` response header. The value of the header `Access-Control-Allow-Headers` is same as the `Access-Control-Request-Headers` header provided by the client. If the header `Access-Control-Request-Headers` is not included in the request, the gateway will omit the `Access-Control-Allow-Headers` response header, instead of specifying the `*` wildcard. A Gateway implementation may choose to add implementation-specific default headers.


        Support: Extended

      • setAllowHeaders

        public void setAllowHeaders​(List<String> allowHeaders)
        AllowHeaders indicates which HTTP request headers are supported for accessing the requested resource.


        Header names are not case sensitive.


        Multiple header names in the value of the `Access-Control-Allow-Headers` response header are separated by a comma (",").


        When the `AllowHeaders` field is configured with one or more headers, the gateway must return the `Access-Control-Allow-Headers` response header which value is present in the `AllowHeaders` field.


        If any header name in the `Access-Control-Request-Headers` request header is not included in the list of header names specified by the response header `Access-Control-Allow-Headers`, it will present an error on the client side.


        If any header name in the `Access-Control-Allow-Headers` response header does not recognize by the client, it will also occur an error on the client side.


        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 `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowHeaders` field specified with the `*` wildcard, the gateway must specify one or more HTTP headers in the value of the `Access-Control-Allow-Headers` response header. The value of the header `Access-Control-Allow-Headers` is same as the `Access-Control-Request-Headers` header provided by the client. If the header `Access-Control-Request-Headers` is not included in the request, the gateway will omit the `Access-Control-Allow-Headers` response header, instead of specifying the `*` wildcard. A Gateway implementation may choose to add implementation-specific default headers.


        Support: Extended

      • getAllowMethods

        public List<String> getAllowMethods()
        AllowMethods indicates which HTTP methods are supported for accessing the requested resource.


        Valid values are any method defined by RFC9110, along with the special value `*`, which represents all HTTP methods are allowed.


        Method names are case sensitive, so these values are also case-sensitive. (See https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1)


        Multiple method names in the value of the `Access-Control-Allow-Methods` response header are separated by a comma (",").


        A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`. (See https://fetch.spec.whatwg.org/#cors-safelisted-method) The CORS-safelisted methods are always allowed, regardless of whether they are specified in the `AllowMethods` field.


        When the `AllowMethods` field is configured with one or more methods, the gateway must return the `Access-Control-Allow-Methods` response header which value is present in the `AllowMethods` field.


        If the HTTP method of the `Access-Control-Request-Method` request header is not included in the list of methods specified by the response header `Access-Control-Allow-Methods`, it will present an error on the client side.


        The `Access-Control-Allow-Methods` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowMethods` field specified with the `*` wildcard, the gateway must specify one HTTP method in the value of the Access-Control-Allow-Methods response header. The value of the header `Access-Control-Allow-Methods` is same as the `Access-Control-Request-Method` header provided by the client. If the header `Access-Control-Request-Method` is not included in the request, the gateway will omit the `Access-Control-Allow-Methods` response header, instead of specifying the `*` wildcard. A Gateway implementation may choose to add implementation-specific default methods.


        Support: Extended

      • setAllowMethods

        public void setAllowMethods​(List<String> allowMethods)
        AllowMethods indicates which HTTP methods are supported for accessing the requested resource.


        Valid values are any method defined by RFC9110, along with the special value `*`, which represents all HTTP methods are allowed.


        Method names are case sensitive, so these values are also case-sensitive. (See https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1)


        Multiple method names in the value of the `Access-Control-Allow-Methods` response header are separated by a comma (",").


        A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`. (See https://fetch.spec.whatwg.org/#cors-safelisted-method) The CORS-safelisted methods are always allowed, regardless of whether they are specified in the `AllowMethods` field.


        When the `AllowMethods` field is configured with one or more methods, the gateway must return the `Access-Control-Allow-Methods` response header which value is present in the `AllowMethods` field.


        If the HTTP method of the `Access-Control-Request-Method` request header is not included in the list of methods specified by the response header `Access-Control-Allow-Methods`, it will present an error on the client side.


        The `Access-Control-Allow-Methods` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowMethods` field specified with the `*` wildcard, the gateway must specify one HTTP method in the value of the Access-Control-Allow-Methods response header. The value of the header `Access-Control-Allow-Methods` is same as the `Access-Control-Request-Method` header provided by the client. If the header `Access-Control-Request-Method` is not included in the request, the gateway will omit the `Access-Control-Allow-Methods` response header, instead of specifying the `*` wildcard. A Gateway implementation may choose to add implementation-specific default methods.


        Support: Extended

      • getAllowOrigins

        public List<String> getAllowOrigins()
        AllowOrigins indicates whether the response can be shared with requested resource from the given `Origin`.


        The `Origin` consists of a scheme and a host, with an optional port, and takes the form `<scheme>://<host>(:<port>)`.


        Valid values for scheme are: `http` and `https`.


        Valid values for port are any integer between 1 and 65535 (the list of available TCP/UDP ports). Note that, if not included, port `80` is assumed for `http` scheme origins, and port `443` is assumed for `https` origins. This may affect origin matching.


        The host part of the origin may contain the wildcard character `*`. These wildcard characters behave as follows:


        * `*` is a greedy match to the _left_, including any number of

        DNS labels to the left of its position. This also means that

        `*` will include any number of period `.` characters to the

        left of its position.

        * A wildcard by itself matches all hosts.


        An origin value that includes _only_ the `*` character indicates requests from all `Origin`s are allowed.


        When the `AllowOrigins` field is configured with multiple origins, it means the server supports clients from multiple origins. If the request `Origin` matches the configured allowed origins, the gateway must return the given `Origin` and sets value of the header `Access-Control-Allow-Origin` same as the `Origin` header provided by the client.


        The status code of a successful response to a "preflight" request is always an OK status (i.e., 204 or 200).


        If the request `Origin` does not match the configured allowed origins, the gateway returns 204/200 response but doesn't set the relevant cross-origin response headers. Alternatively, the gateway responds with 403 status to the "preflight" request is denied, coupled with omitting the CORS headers. The cross-origin request fails on the client side. Therefore, the client doesn't attempt the actual cross-origin request.


        The `Access-Control-Allow-Origin` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowOrigins` field specified with the `*` wildcard, the gateway must return a single origin in the value of the `Access-Control-Allow-Origin` response header, instead of specifying the `*` wildcard. The value of the header `Access-Control-Allow-Origin` is same as the `Origin` header provided by the client.


        Support: Extended

      • setAllowOrigins

        public void setAllowOrigins​(List<String> allowOrigins)
        AllowOrigins indicates whether the response can be shared with requested resource from the given `Origin`.


        The `Origin` consists of a scheme and a host, with an optional port, and takes the form `<scheme>://<host>(:<port>)`.


        Valid values for scheme are: `http` and `https`.


        Valid values for port are any integer between 1 and 65535 (the list of available TCP/UDP ports). Note that, if not included, port `80` is assumed for `http` scheme origins, and port `443` is assumed for `https` origins. This may affect origin matching.


        The host part of the origin may contain the wildcard character `*`. These wildcard characters behave as follows:


        * `*` is a greedy match to the _left_, including any number of

        DNS labels to the left of its position. This also means that

        `*` will include any number of period `.` characters to the

        left of its position.

        * A wildcard by itself matches all hosts.


        An origin value that includes _only_ the `*` character indicates requests from all `Origin`s are allowed.


        When the `AllowOrigins` field is configured with multiple origins, it means the server supports clients from multiple origins. If the request `Origin` matches the configured allowed origins, the gateway must return the given `Origin` and sets value of the header `Access-Control-Allow-Origin` same as the `Origin` header provided by the client.


        The status code of a successful response to a "preflight" request is always an OK status (i.e., 204 or 200).


        If the request `Origin` does not match the configured allowed origins, the gateway returns 204/200 response but doesn't set the relevant cross-origin response headers. Alternatively, the gateway responds with 403 status to the "preflight" request is denied, coupled with omitting the CORS headers. The cross-origin request fails on the client side. Therefore, the client doesn't attempt the actual cross-origin request.


        The `Access-Control-Allow-Origin` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        When the `AllowCredentials` field is true and `AllowOrigins` field specified with the `*` wildcard, the gateway must return a single origin in the value of the `Access-Control-Allow-Origin` response header, instead of specifying the `*` wildcard. The value of the header `Access-Control-Allow-Origin` is same as the `Origin` header provided by the client.


        Support: Extended

      • getExposeHeaders

        public List<String> getExposeHeaders()
        ExposeHeaders indicates which HTTP response headers can be exposed to client-side scripts in response to a cross-origin request.


        A CORS-safelisted response header is an HTTP header in a CORS response that it is considered safe to expose to the client scripts. The CORS-safelisted response headers include the following headers: `Cache-Control` `Content-Language` `Content-Length` `Content-Type` `Expires` `Last-Modified` `Pragma` (See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name) The CORS-safelisted response headers are exposed to client by default.


        When an HTTP header name is specified using the `ExposeHeaders` field, this additional header will be exposed as part of the response to the client.


        Header names are not case sensitive.


        Multiple header names in the value of the `Access-Control-Expose-Headers` response header are separated by a comma (",").


        A wildcard indicates that the responses with all HTTP headers are exposed to clients. The `Access-Control-Expose-Headers` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        Support: Extended

      • setExposeHeaders

        public void setExposeHeaders​(List<String> exposeHeaders)
        ExposeHeaders indicates which HTTP response headers can be exposed to client-side scripts in response to a cross-origin request.


        A CORS-safelisted response header is an HTTP header in a CORS response that it is considered safe to expose to the client scripts. The CORS-safelisted response headers include the following headers: `Cache-Control` `Content-Language` `Content-Length` `Content-Type` `Expires` `Last-Modified` `Pragma` (See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name) The CORS-safelisted response headers are exposed to client by default.


        When an HTTP header name is specified using the `ExposeHeaders` field, this additional header will be exposed as part of the response to the client.


        Header names are not case sensitive.


        Multiple header names in the value of the `Access-Control-Expose-Headers` response header are separated by a comma (",").


        A wildcard indicates that the responses with all HTTP headers are exposed to clients. The `Access-Control-Expose-Headers` response header can only use `*` wildcard as value when the `AllowCredentials` field is false or omitted.


        Support: Extended

      • getMaxAge

        public Integer getMaxAge()
        MaxAge indicates the duration (in seconds) for the client to cache the results of a "preflight" request.


        The information provided by the `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` response headers can be cached by the client until the time specified by `Access-Control-Max-Age` elapses.


        The default value of `Access-Control-Max-Age` response header is 5 (seconds).

      • setMaxAge

        public void setMaxAge​(Integer maxAge)
        MaxAge indicates the duration (in seconds) for the client to cache the results of a "preflight" request.


        The information provided by the `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` response headers can be cached by the client until the time specified by `Access-Control-Max-Age` elapses.


        The default value of `Access-Control-Max-Age` response header is 5 (seconds).

      • getAdditionalProperties

        public Map<String,​Object> getAdditionalProperties()

      • setAdditionalProperty

        public void setAdditionalProperty​(String name,
                                  Object value)

      • setAdditionalProperties

        public void setAdditionalProperties​(Map<String,​Object> additionalProperties)