On 3/29/12 5:32 PM, Marcel Overdijk wrote:
> 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.

You would have the same problem if you didn't use Resteasy.  The request 
would be committed (headers written) when you flush the output stream 
when writing a http message body.  Unless this filter totally wrapped 
HttpServletResponse and buffered the whole response, the filter would 
not be able to add response headers after the request chain was 
processed.  Am I making sense?

> I tried to make this more generic with wildcard pattern like
>      @OPTIONS
>      @Path("**")
>      public void options() {
>      }
> but this didn't work unfortunately.

Your wildcard expression is incorrect:

@Path("{path : .*}")
public void options() {...}

Bill Burke
JBoss, a division of Red Hat

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Resteasy-users mailing list

Reply via email to