- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Dec 2011 15:53:36 -0800
- To: Benson Margulies <bimargulies@gmail.com>
- Cc: public-webapps@w3.org
On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies <bimargulies@gmail.com> wrote: > There's a problem with REST-ful services, as exemplified by the JAX-RS > standard, and CORS as drafted. > > A JAX-RS server names a resource, in part, via the content-type of a > request. A POST with content-type of application/json names a > different resource (in as much as it selects a different method to > call) that a POST with content-type text/plain. > > The problem here is that a preflight OPTIONS is defined to *not* pass > the content type unless it is simple. Thus, the service implementation > can't reliably tell what resource is under discussion. > > As things are, a service would have to take a common posture for all > preflights given the URL and Accept(-*) headers, and ignoring the > content type. > > Would you consider defining an Ac-Request-Content-Type header to pass > a non-simple content type on a preflight? You can always allow the OPTIONS request and make the security decision once you get the actual request. The main point of the OPTIONS request is to protect servers that aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into this category. / Jonas
Received on Thursday, 1 December 2011 23:54:43 UTC