On 2011-12-01 21:20, Benson Margulies 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.
That seems to be entirely JAX-RS problem. The *resource* is supposed to
be identified by the request-URI.
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.
Even if OPTIONS would be sent with a Content-Type header field, that
field, by definition, would identify the internet media type of the
request body.
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.
Absolutely.
Would you consider defining an Ac-Request-Content-Type header to pass
a non-simple content type on a preflight?
Unless I'm missing something here you are definitively trying to do the
wrong thing.
Best regards, Julian
