I'm facing a big issue with setting response headers.
In fact I'm not able to set them at all :-(
I'm implementing a Cross Origin Resource Sharing (CORS) server with
Resteasy.
The server will receive requests like:
GET /customers - returns a JSON response with a list of customers
POST /customers - receives a JSON body and creates a customer
GET /customers/1 - returns a JSON response with customer 1
PUT /customers/1 - receives a JSON body and updates customer 1
DELETE /customers/1 - Deletes customer 1
The actual calls to this server will be made from a mobile application so
CORS is needed to 'workaround' the same origin policy.
With the above requirements this means the server will receive - as the
CORS spec states - preflighted requests so the server can determine if the
requested action should be accepted.
In practice this means the client will send an OPTIONS preflight request
before the actual request with the following headers:
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Accept, Content-Type, Origin,
X-Requested-With
And the server will send back something like:
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Accept, Content-Type, Origin, X-Requested-With
Access-Control-Max-Age: 1800
(1)
My first stake was to write an ordinary Servlet Filter which would just add
above headers to each response.
Note that my Resteasy resources were setup in a way that they are not
containing mappings for the OPTIONS request, hence the filter would just
return those headers for all requests.
I tried with putting this CorsFilter before and after the
Resteasy FilterDispatcher but had no luck.
When I put the CorsFilter before the FilterDispatcher I can see that it
enters the CorsFilter (and adds the headers) but the FilterDispatcher seems
to hijack this completely and the headers are not anymore in the response.
Probably this is inteded, and if not I would like to hear it.
(2)
My second try was to use a Resteasy PostProcessor interceptor.
But this interceptor was not executed for my OPTIONS request, so again the
needed repsonse headers were not there.
I figured out that this is probably because the OPTIONS request is not
mapped in my resources and so Resteasy will not intercept it, right?
(3)
Still looking for an easy solution here (to stay in terms with Rest'easy')
I thought I had found a clever solution by just adding a generic OPTIONS
mapping for in all my resources like:
@Path("/customers")
public class CustomersResource {
@OPTIONS
public void options() {
// this is just here to make sure resteasy can map options request
and it will be picked up by the interceptor
}
This works really well for OPTIONS /customers
but not for OPTIONS /customers/1
or other resources like OPTIONS /customers/1/invoices
I tried to make this more generic with wildcard pattern like
@OPTIONS
@Path("**")
public void options() {
}
but this didn't work unfortunately.
This is getting a lengthy post now, so this should explain my problems.
I hope somebody has an easy solution to workaround.
Help would be really appreciated.
Cheers,
Marcel
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
