Re: [cors] JAX-RS and preflight

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.

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.

All of those facts are available to a preflight except for the content
type when the content-type is non-simple.

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.

Obviously, if you do reject this, it will not be the end of the
internet as we know it.



On Thu, Dec 1, 2011 at 3:57 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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
>

Received on Thursday, 1 December 2011 23:12:26 UTC