Hi Bill,

Thanks for pointing out the incorrect path expression.
As you suggested I tried:

@Path("{path : .*}")

but this only maps to e.g.

/customers/1
/customers/1/some/path

but not to

/customers

itself.
Is there some way I can use set the @Path that it maps to
/customers
/customers/any/path

On Fri, Mar 30, 2012 at 4:42 PM, Bill Burke <bbu...@redhat.com> wrote:

>
>
> 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:
>
> @OPTIONS
> @Path("{path : .*}")
> public void options() {...}
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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

Reply via email to