Bug 57180

Bugzilla is not a support forum. If you need help, please post to the user's mailing list.

Hint: you can set the "cors.allowed.methods" init-param for the CorsFilter and allow whatever HTTP methods you want. By default, the filter supports GET,POST,HEAD,OPTIONS but you can add whatever you want to that list.

http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

This isn't a help request; it's a bug report.

Irrespective of allowed methods, the preflight filter evaluates the following:
"if (method != null && HTTP_METHODS.contains(method)) {" as well as "else if (COMPLEX_HTTP_METHODS.contains(method)) {"

Neither HTTP_METHODS nor COMPLEX_HTTP_METHODS contain "PATCH" hence, the original definition of "CORSRequestType requestType = CORSRequestType.INVALID_CORS;" is used.

Adding "PATCH" to both HTTP_METHODS and COMPLEX_HTTP_METHODS just purely enables the use of the allowed methods filter param.

I have removed the check against complex methods.

This has been fixed in trunk 8.0.x (for 8.0.16 onwards) and 7.0.x (for 7.0.58 onwards).

Fantastic! Thanks, Mark.

Seems like this is still broken in 8.0.18. The check for a valid cors method is gated by a check against HTTP_METHODS, which doesn't include PATCH. 

Note there is an additional spec for the addition of PATCH:
http://tools.ietf.org/html/rfc5789

/**
     * {@link Collection} of HTTP methods. Case sensitive.
     *
     * @see  <a href="http://tools.ietf.org/html/rfc2616#section-5.1.1"
     *       >http://tools.ietf.org/html/rfc2616#section-5.1.1</a>
     *
     */
    public static final Collection<String> HTTP_METHODS =
            new HashSet<>(Arrays.asList("OPTIONS", "GET", "HEAD", "POST", "PUT",
                    "DELETE", "TRACE", "CONNECT"));

Additional fix applied to trunk, 8.0.x (for 8.0.19 onwards) and 7.0.x (for 7.0.60 onwards).