It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey, WTYT? I'm sure it's
not a tragedy and that I could fix that easily enough.
It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey,
Hi there
I was working in the last 5 months in enabling tomcat for federation and
propagate the security context of the browser user to the back end web services
using the CXF STS.
I just committed this code to the cxf sandbox:
http://svn.apache.org/viewvc/cxf/sandbox/fediz/
This project
Hi Benson
On 21/12/11 18:32, Benson Margulies wrote:
It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey, WTYT? I'm sure it's
not a tragedy and that I could fix that easily enough.
Which headers are you referring to, the ones that
On 21/12/11 22:23, Sergey Beryozkin wrote:
Hi Benson
On 21/12/11 18:32, Benson Margulies wrote:
It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey, WTYT? I'm sure it's
not a tragedy and that I could fix that easily enough.
Which
http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#author-request-headers
demands case-sensitive comparison.
Chrome sends, e.g.:
Access-Control-Request-Headers: Content-Type
Firefox sends, e.g.
Access-Control-Request-Headers: content-type
Should we violate the spec and do a
