Re: JAX-RS - CORS OPTIONS/LocalPreflight error 400

[Sergey Beryozkin]

On 12/07/12 12:47, ramesh wrote:
On 07/12/2012 04:35 AM, Sergey Beryozkin wrote:
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



What a way to start a day , with a working CORS :)
I tried almost everything last night , but it did not occur to me, that
I can pass both POST & OPTIONS.
Did not even bother @LocalPreflight this time.

@CrossOriginResourceSharing(
allowHeaders = {
}
)
at class level

and on method

@POST
@OPTIONS
Response addCustomer(Customer customer);

This is cool, good news. What happens in this case is that @OPTIONS are 
ignored - at the JAX-RS level, this is illegal really in JAX-RS to have 
two method annotations, but CXF is lax at the moment, this will be 
reported at the validation time in the future versions.

By the way, the use of @CrossOriginResourceSharing is optional too, all 
the properties can be set on the filter.

Please experiment more with making the filter a bit more restrictive and 
see what happens, I guess the allowOrigins property is of major interest 


And the magic happened.

Thanks again for making CXF so simple.

Credit goes to Benson

Sergey

regards
Ramesh