Hi
On 12/07/12 05:36, ramesh wrote:
Hi,
Seems like JAX-RS CORS is about work for me. I am finally getting 400
error if the method uses @LocalPreflight.
**My previous logs I posted were wrong, because my bundles were not
updating.
thanks for the update, I'd like to see it all working as expected, that
would be an important validation step for the CXF CORS module. I'm sure
Benson is running it successfully too :-)
So like Preflight is suppose to act, after verification from server of
Access-Control-Allow-Methods and Access-Control-Allow-Headers,
it should make the POST( in my case ), but that is where it is failing
with 400.
---------------------------
Http-Method: OPTIONS
Content-Type:
Headers:
{Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8],
accept-encoding=[gzip, deflate], Accept-Language=[en-us,en;q=0.5],
Access-Control-Request-Headers=[content-type],
Access-Control-Request-Method=[POST], Cache-Control=[no-cache],
connection=[keep-alive], Content-Type=[null], Host=[localhost:8181],
Origin=[http://localhost], Pragma=[no-cache], User-Agent=[Mozilla/5.0
(X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1]}
ID: 49
Response-Code: 400
Content-Type: text/plain
Headers: {Content-Type=[text/plain], Date=[Thu, 12 Jul 2012 04:15:21 GMT]}
I am also getting warning , http://pastebin.com/6QSwdbXM .
-----------------------------------------------------------------------------------------------
If the don't use @LocalPreflight and leave it to filter, I get this
warning and 405 error code. It seems like resource is re-requested at
localhost/cxf/hi/for , instead of localhost:8181/cxf/hi/for
| WARN | qtp363775074-93 | JAXRSUtils | 117 -
org.apache.cxf.cxf-rt-frontend-jaxrs - 2.6.1 | No operation matching
request path "/cxf/hi/for" is found, Relative Path: /, HTTP Method:
POST, ContentType: */*, Accept: */*,. Please enable FINE/TRACE log level
for more details.
2012-07-11 23:13:06,500 | INFO | qtp363775074-93 | LoggingOutInterceptor
| 81 - org.apache.cxf.cxf-api - 2.6.1 | Outbound Message
---------------------------
ID: 46
Response-Code: 405
Content-Type: text/xml
Headers: {Allow=[GET, OPTIONS, HEAD], Date=[Thu, 12 Jul 2012 04:13:06
GMT], Content-Length=[0]}
So we have a non 'simple' (in CORS terms) POST request to make. In this
case the browser is issuing a preflight OPTIONS first. Now,
If you have a custom resource method annotated with @LocalPreflight
(meaning the filter won't attempt to do it yourself) and @OPTIONS then
at what point do you see 400 ? Is it after your resource method returns
a preflight response to the browser and the browser issues the actual POST ?
If you let the filter do a preflight, you see 405, after the filter
responded to the browser and the browser issued actual POST. 'Allow'
header in the response suggests that POST is not even available in the
resource code.
Cheers, Sergey
any help appreciated
regards,
Ramesh
