On 2011-12-02 00:11, Benson Margulies wrote:
Let me try to present this more clearly.
First of all, I did not design or implement JAX-RS itself. The
committee that designed it might have done something wrong in their
dispatching approach. However, *I* am merely working on implementing a
facility for the resource side of CORS in a JAX-RS framework.
And I have to admit that I'm a member of that Expert Group. Apparently
not paying sufficient attention, though.
Perhaps it would be less disturbing if I characterized the situation
as follows: JAX-RS dispatches the job of serving content at a smaller
granularity than an HTTP/CORS 'resource'. It operates on the
combination of resource+content-type+accepts+accepts-language.
Varying the *response* based on Accept and Accept-Language is ok. It
doesn't change the resource you're talking to, though.
Content-Type really doesn't belong into this at all.
All of those facts are available to a preflight except for the content
type when the content-type is non-simple.
That may be true, but doesn't affect what HTTP resource you're talking to.
My humble request is for you to consider defining one more 'request'
header for preflight: access-control-request-content-type -- that the
client would send to the server on the OPTIONS command.
There are many, many, services written with JAX-RS -- representing a
classic case of that old standardization chestnut: 'existing
practice.' What I'm proposing here would be trivial for client
implementations, so I would think that the authors of the CORS
proposal would at least grant this idea a full 5 minutes of thought
before rejecting it.
Please don't. It's totally the wrong thing to do here.
If JAX-RS takes the position that the Content-Type on a request affects
the resource being identified it totally needs to be fixed.
...
Best regards, Julian
