Re: CorsFilter denying some same-origin requests.
Having re-read the specs I can see that trying to match origins by resolving to IP addresses is not a good idea. However, that still leaves us with a problem because Chrome sends an Origin header for some same-origin requests. The CorsFilter denies these requests if the origin is not in cors.allowed.origins. We have too many possible origins to be able to specify them all in the deployment descriptor (and we don't want to allow all origins). One solution would be to treat requests as non-CORS when the Origin and Host headers match (having pre-appended the request scheme to the Host header). Do you think that this is something that Apache would consider incorporating into the CORS filter? This would be preferable to maintaining our own copy of the filter indefinitely. Thanks Richard On Mon, Mar 10, 2014 at 3:55 PM, Mark Thomas ma...@apache.org wrote: On 10/03/2014 14:30, Richard Hart wrote: (Tomcat 7.0.50, Linux) Having recently enabled CORS support for our Tomcat-based web app using the provided CorsFilter, we have discovered a problem where some same-origin (i.e. non-CORS) requests from certain browsers (e.g. Chrome) are denied. This is due to the browser setting the Origin header even though the request is non-CORS. it turns out that this is in fact legal according to RFC 6454. Given the popularity of Tomcat and Chrome I was surprised to find little mention of this problem online. Has anyone else encountered this problem? Our planned solution is to fork CorsFilter and and modify it to allow requests for which the Origin and Host headers both resolve to the same IP address. However, if somebody has already implemented a solution for this problem could you please let us know. If the Origin and Host headers don't match (even if they do resolve to the same IP address) isn't that a cross-origin request? In which case isn't the filter doing what it is meant to? Why isn't setting the cors.allowed.origins init parameter sufficient? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CorsFilter denying some same-origin requests.
(Tomcat 7.0.50, Linux) Having recently enabled CORS support for our Tomcat-based web app using the provided CorsFilter, we have discovered a problem where some same-origin (i.e. non-CORS) requests from certain browsers (e.g. Chrome) are denied. This is due to the browser setting the Origin header even though the request is non-CORS. it turns out that this is in fact legal according to RFC 6454. Given the popularity of Tomcat and Chrome I was surprised to find little mention of this problem online. Has anyone else encountered this problem? Our planned solution is to fork CorsFilter and and modify it to allow requests for which the Origin and Host headers both resolve to the same IP address. However, if somebody has already implemented a solution for this problem could you please let us know.. Thanks Richard Hart - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CorsFilter denying some same-origin requests.
On 10/03/2014 14:30, Richard Hart wrote: (Tomcat 7.0.50, Linux) Having recently enabled CORS support for our Tomcat-based web app using the provided CorsFilter, we have discovered a problem where some same-origin (i.e. non-CORS) requests from certain browsers (e.g. Chrome) are denied. This is due to the browser setting the Origin header even though the request is non-CORS. it turns out that this is in fact legal according to RFC 6454. Given the popularity of Tomcat and Chrome I was surprised to find little mention of this problem online. Has anyone else encountered this problem? Our planned solution is to fork CorsFilter and and modify it to allow requests for which the Origin and Host headers both resolve to the same IP address. However, if somebody has already implemented a solution for this problem could you please let us know. If the Origin and Host headers don't match (even if they do resolve to the same IP address) isn't that a cross-origin request? In which case isn't the filter doing what it is meant to? Why isn't setting the cors.allowed.origins init parameter sufficient? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
