W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: PUT and DELETE methods in 200 code

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Mon, 4 Apr 2011 17:08:42 +0100
Cc: mike amundsen <mamund@yahoo.com>, public-html@w3.org
Message-Id: <48050C74-3DF2-4CFC-A840-1D012271AD7A@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>

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:09:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC