1

I am currently experimenting with IBM JAX-RS capability through WAS 7 and Web 2.0 Feature Pack 1.1.0.0. The problem I am running into is the client Dojo ajax call poses CORS situation and I am basically trying to figure out how I could properly handle the OPTIONS request.

I followed the example in the referenced url (although it's for WAS 8, it should not affect the part I am playing with); however, it is reported that the system cannot find any method that supports OPTIONS.

Any help will be appreciated!

Reference URL: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-base-iseries&topic=twbs_jaxrs_wadl_serving

JustGFW
  • 11
  • 1

1 Answers1

0

Although it's less than a day, since I did not see any response, I want to post out the temp solution I pieced so far.

First of all, check out below link from Mozilla for a better understanding of CORS and OPTIONS request (it did the trick for me).

Link: https://developer.mozilla.org/en-US/docs/HTTP_access_control

Next, one update on the problem of IBM JAX-RS handling OPTIONS. It appears OPTIONS request is handled no different than other GET/POST, it requires an exact match of @Path value. This is not really desired, and in my case, I tried wild card in @Path value, that did not do the trick of triggering the system to handle OPTIONS.

Now, for the solution. With no surprise, I end up using a filter to forward the OPTIONS request to a method inside the resource annotated with @OPTIONS and fixed @Path value, e.g. @Path("options").

In filter, I am handling Allow-Origin and Allow-Header, then I left the resource's @OPTION method to deal with Allow-Methods.

It is very simple and basic solution. Along with proper checking inside filter, the header does not need to be added excessively for every request.

One catch here, it works for Chrome (Version 23.0.1271.95 m) and Mozilla (9.0.1), but not IE. I am still trying to figure out how IE is responding to these CORS. Hope this helps.

JustGFW
  • 11
  • 1