W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [cors] JAX-RS and preflight

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Dec 2011 15:53:36 -0800
Message-ID: <CA+c2ei_g7oCj+WgtAD7Xz-xssgzqUVxQ3w_dN9sOoZHkdTxDOA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC