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
{{ message }}
This repository has been archived by the owner on Jul 16, 2019. It is now read-only.
"The presence of the Origin header does not necessarily mean that the request is a cross-origin request. While all cross-origin requests will contain an Origin header, some same-origin requests might have one as well. For example, Firefox doesn't include an Origin header on same-origin requests. But Chrome and Safari include an Origin header on same-origin POST/PUT/DELETE requests (same-origin GET requests will not have an Origin header)."
Now because Chrome is also sending an origin header on same-origin requests they get treated as CORS requests by the CORSFilter. As soon as one defines "cors.allowed.origins" to a specific list of domains, which does not include the same-origin domain, these same-origin requests get a response of 403.
I guess this is incorrect.
Best regards,
Ronald
The text was updated successfully, but these errors were encountered:
The filter is a reference implementation of W3C's CORS specification. Specifically, the resource processing model section. As per that section, if a request does contain 'Origin' header, than the resource should treat the request as a cross-origin request, and process it accordingly.
So, this behavior is correct, as far as the specification is concerned.
Although, it's interesting why chrome and safari (both webkit based), are sending 'Origin' header on same origin requests. I am aware of whatwg's Fetch, where the 'Origin' header is sent, regardless of request being same origin or cross origin.
I would still argue that this is incorrect behaviour. The CORS Spec Abstract says:
"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification."
From this I deduce that the spec is only concerned about cross-origin request and not about same-origin requests. Therefore, in my opinion, the first task of the filter should be to determine if is is a same-origin request and if so let it pass.
In my opinion a CORS filter should not filters out same-origin request which would have been processed without the CORS filter. I do not see that this adds any value.
Hi,
you currently treat only requests without an origin header as CORSRequestType.NOT_CORS
But http://www.html5rocks.com/en/tutorials/cors/ says:
"The presence of the Origin header does not necessarily mean that the request is a cross-origin request. While all cross-origin requests will contain an Origin header, some same-origin requests might have one as well. For example, Firefox doesn't include an Origin header on same-origin requests. But Chrome and Safari include an Origin header on same-origin POST/PUT/DELETE requests (same-origin GET requests will not have an Origin header)."
Now because Chrome is also sending an origin header on same-origin requests they get treated as CORS requests by the CORSFilter. As soon as one defines "cors.allowed.origins" to a specific list of domains, which does not include the same-origin domain, these same-origin requests get a response of 403.
I guess this is incorrect.
Best regards,
Ronald
The text was updated successfully, but these errors were encountered: