- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 01 Dec 2011 21:57:56 +0100
- To: Benson Margulies <bimargulies@gmail.com>
- CC: public-webapps@w3.org
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 20:58:38 UTC