- From: mike amundsen <mamund@yahoo.com>
- Date: Mon, 4 Apr 2011 12:37:00 -0400
- To: Cameron Heavon-Jones <cmhjones@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, public-html@w3.org
<snip> > No problem...i will create the browser tables asap, it might take me a bit longer for WebDAV as i haven't got much experience with these and will need to set them up. </snip> Sounds great. Feel free to post the browser stuff first; we can deal w/ WebDAV along the way. If you want to email me the results directly, that's fine. I'll add it to the doc as soon as I can. Thanks! 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:31, Cameron Heavon-Jones <cmhjones@gmail.com> wrote: > No problem...i will create the browser tables asap, it might take me a bit longer for WebDAV as i haven't got much experience with these and will need to set them up. > > Another area which i will attempt to test is the browser's handling of 3** codes...i think this might be an area where UA behaviour might not align exactly with HTTP spec. > > cam > > > On 04/04/2011, at 5:18 PM, mike amundsen wrote: > >> 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:37:33 UTC