You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Java version/vendor
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu118.04)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu118.04, mixed mode, sharing)
OS type/version
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Description
When running your server with the CrossOriginFilter default filter, OPTIONS responses do not return a Vary header on no-cors requests.
So, others cors requests to the same resource uses the no-cors request cached headers and lack cors headers such as Origin or Access-Control-Allow-Origin.
As explained here, https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches :
In particular, consider what happens if Vary is not used and a server is configured to send Access-Control-Allow-Origin for a certain resource only in response to a CORS request. When a user-agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lack Access-Control-Allow-Origin and the user agent will cache that response. Then, if the user-agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, without Access-Control-Allow-Origin.
After opening this below issue, the submitted fix doesn't seem to fix this issue. #1927
How to reproduce?
Configure your server to use Jetty's default CrossOriginFilter.
Load a resource through your browser with a no-cors request, the Vary: Origin header is not present on the OPTIONS response due to no-cors.
Load the same resource with a cors request, your user-agent won't include the Origin & Access-Control-Allow-Origin header due to caching, the request will be rejected.
The text was updated successfully, but these errors were encountered:
…s mode.
Modified the fix introduced by #9779 to avoid usage of Jetty server classes, so that the CrossOriginFilter can be deployed in any web application.
Signed-off-by: Simone Bordet <[email protected]>
Jetty version(s)
11.0.13
Java version/vendor
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Ubuntu-0ubuntu118.04)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Ubuntu-0ubuntu118.04, mixed mode, sharing)
OS type/version
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Description
When running your server with the CrossOriginFilter default filter, OPTIONS responses do not return a
Vary
header onno-cors
requests.So, others
cors
requests to the same resource uses theno-cors
request cached headers and lack cors headers such asOrigin
orAccess-Control-Allow-Origin
.As explained here, https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches :
In particular, consider what happens if
Vary
is not used and a server is configured to sendAccess-Control-Allow-Origin
for a certain resource only in response to a CORS request. When a user-agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lackAccess-Control-Allow-Origin
and the user agent will cache that response. Then, if the user-agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, withoutAccess-Control-Allow-Origin
.After opening this below issue, the submitted fix doesn't seem to fix this issue.
#1927
How to reproduce?
CrossOriginFilter
.no-cors
request, theVary: Origin
header is not present on the OPTIONS response due tono-cors
.cors
request, your user-agent won't include theOrigin
&Access-Control-Allow-Origin
header due to caching, the request will be rejected.The text was updated successfully, but these errors were encountered: