CorsFilter does not allow requests with the Origin header set to string "null". It treats such requests as invalid CORS requests. The current implementation seems too restrictive and prevents some common use cases: The Origin header is set to "null" when the browser cannot determine the origin of a request. This is the case when opening local files in the browser. Common uses cases are local development with remote services and testing hybrid mobile applications. To support such use cases, a new configuration option could be introduced where administrators could explicitly allow CORS requests with "null" origins.
Created attachment 32185 [details] Patch file for Bug #57178 The attached patch adds a new CorsFilter configuration option to explicitly allow "null" origins: <filter> <filter-name>CorsFilter</filter-name> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class> <init-param> <param-name>cors.allow.nullorigin</param-name> <param-value>true</param-value> </init-param> </filter> When enabled, requests with "null" origins are processed as valid CORS requests. (The option is disabled by default.)
Comment on attachment 32185 [details] Patch file for Bug #57178 Ping. Reminder to me to look at this next week. Quick scan of the patch looks OK but I need to look at it in the context of the whole code.
Having had a closer look at this, I'm wondering why another configation option is needed. Why not just add "null" to the list of allowed origins? (This would still requires a small patch so null is accepted as a valid origin.)
No, is not needed, but I initially thought of a separate configuration option for making the decision of whether to allow the null origin more explicit. This also allows to control whether the default value "*" (any origin) of the existing configuration option 'cors.allowed.origins' includes or excludes the null origin. The proposed patch does not alter the current default behavior: if 'cors.allowed.origins' is set to "*", then the null origin is not allowed. It must be explicitly enabled by setting the new configuration option 'cors.allowed.nullorigins' to true, which might be useful for specific configuration needs.
What is the use case for excluding the null origin but allowing all others? I've been reading through the CORS spec and related documents and haven't seen anything that suggests a use case. What I have read suggests that null should always be included in *.
That is correct, the only use case would be really just supporting the current behavior. I would also prefer considering this behavior a bug and handle "null" as a valid origin (for both the default "*" case and when explicitly configured with "null" using the cors.allowed.origins parameter). I will follow up with a simplified patch without any new configuration options shortly.
Created attachment 32389 [details] Simplified patch for Bug#57178 Simplified patch to handle "null" as a valid origin.
Thanks for the updated patch. The fix has been applied to trunk, 8.0.x (for 8.0.18 onwards) and 7.0.x (for 7.0.58 onwards).