- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 11 Mar 2011 20:54:20 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Robert Brewer <fumanchu@aminus.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 11.03.2011 20:45, Roy T. Fielding wrote: > On Mar 11, 2011, at 10:59 AM, Robert Brewer wrote: > >> http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1158 >> modified section 7.6.p.5 to say: >> >> "For example, if the target resource is configured to always >> have a Content-Type of "text/html" and the representation being >> PUT has a Content-Type of "image/jpeg", then the origin server >> SHOULD do one of: (a) reconfigure the target resource to >> reflect the new media type; (b) transform the PUT representation >> to a format consistent with that of the resource before saving >> it as the new resource state; or, (c) reject the request with a >> 409 response indicating that the target resource is limited to >> "text/html", perhaps including a link to a different resource >> that would be a suitable target for the new representation. >> >> Roy, can you explain why 409 is a better choice than 415 in case (c)? > > It is just a slight preference for uniform handling of PUT > (409 is also used by webdav, IIRC). 415 was created for POST ...WebDAV does use 409 in several places, but it doesn't say anything specific about PUT. (as far as I recall) > handling processes. It could go either way for this example. > > Anyone know of implementations that do this kind of error? I believe Spring/Rest will return 415 if the media type isn't accepted. Best regards, Julian
Received on Friday, 11 March 2011 19:55:07 UTC