Re: [cors] JAX-RS and preflight

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

Received on Thursday, 1 December 2011 23:25:02 UTC