Re: PUT and DELETE methods in 200 code

cam:

thanks for the info.  Any chance you'd be able to work up two small
matrix tables? One for Browsers (FF, IE, Safari, Chrome, Opera) +
Response and one for WebDAV (mod_dav, MSFT IIS, others?) + Response?

I'd be happy to add your contribution to my working document.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2010
http://rest-fest.googlecode.com




On Mon, Apr 4, 2011 at 12:08, Cameron Heavon-Jones <cmhjones@gmail.com> wrote:
>
> On 04/04/2011, at 8:36 AM, Julian Reschke wrote:
>> WebDAV clients usually aren't interested in the response bodies for successful PUT/DELETE requests; for them what matters is just the status code.
>>
>> I know of WebDAV servers that simply sent empty response bodies, but also some which send a small "status" message in HTML format (I think this is the case for Apache/mod_dav).
>>
>> So sending additional data is almost harmless; except when it makes the protocol inefficient. For instance, echoing the the representation in a PUT response would be very bad for everything but small payloads.
>>
>
> I agree that additional data is harmless as it will be ignored by anything which can't handle it or doesn't expect it.
>
> I suspect the reason WebDAV returns a small status message is for developer debugging.
>
> Since PUT and DELETE responses are non-cachable, the default behaviour to avoid protocol inefficiencies should be to return no content - unless the client has specifically requested content.
>
> A html representation is a valid response body for PUT and DELETE, especially if it was the format of request generation as is the case from forms. It need not be a full representation of the resource, which would be overkill for an operation over that representation, but should be a formatted response to the request - WebDAV has chosen plain text to represent this.
>
> With some further investigation, it would appear that user agents (firefox 3.x and safari 5.x on osx tested) will render the response body in the result of any status code. One caveat to this is in the case of 204 which includes body content - both browsers translate this to a 200 and render the enclosed content.
>
> This would imply that there is no additional requirement on browser implementers in order to support the responses of form requests, including any client or server http error codes. They also include the Accept header in all requests which provides the ability for services to apply content negotiation rules as normal.
>
> cam
>
>
>
>
>

Received on Monday, 4 April 2011 16:18:54 UTC