https://bz.apache.org/bugzilla/show_bug.cgi?id=67472
lmedini <lmed...@protonmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from lmedini <lmed...@protonmail.com> ---
I am aware that (1) it is not common to use the same server for both
server-side applications and CORS-enabled web APIs, and (2) most developers
will configure CORS on a per-application basis, which is probably why nobody
has had this problem before. In my case, I am teaching the servlet API (the
basics) and web APIs to master degree students, and wish to provide them with
an infrastructure that they will be able to use during all this class. That is
why I chose this solution and need a CORS filter that only operates for CORS
requests. Even if this is not a common need, my claim is that it is the spec's
normal behavior. ;-)
Regarding the note about caching: I am not sure that many clients will send the
same requests (for non-static resources, otherwise, they should not be served
by an application server) in both same-origin and CORS modes. Anyhow, it is the
role of the Vary header to specify if CORS headers should be taken into account
for caching resources, so removing "Origin" from this header should allow
caching resources across CORS and non-CORS requests.
--------
Despite the code comment, I confirm that this behavior does harm in some cases.
>From my experience, the CORS filter blocks requests with proxied URIs and POST
method. I am unsure of its behavior with other preflight requests, but it is
likely to be the same.
So that you can test and reproduce it, kindly check
https://github.com/lmedini/cors-war-test
You will need a reverse proxy, in addition to Tomcat. You will find detailed
explanations about configuration, installation and unexpected behavior in the
readme of this repo.
Thank you in advance.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
