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

Re: Follow-up about PUT and DELETE in form methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 13 Dec 2011 16:10:05 +0100
Message-ID: <4EE76ACD.2060400@gmx.de>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 2011-12-13 15:25, Cameron Heavon-Jones wrote:
> ...
> It's not a question of 'getting it to work', it is a question of whether it is correct to assume that the same request should result in two different responses - that is wrong.
> ...

No, the same request should indeed result in the same response! Of course!

So if we want servers to be able to continue to return 204 on DELETE, 
but also want to enable servers to send a rich HTML page to browsers, 
we'd need to make the requests different.

> unfortunately we're discussing specific implementations - a WebDAV server. This isn't even spec'd WebDAV behaviour, it's just what current servers are doing. There is no foundation to expect existing services to magically just start integrating with new clients. WebDAV servers are written for WebDAV clients, not HTML browser clients. Servers *CAN* be written to support both with content-negotation, it's just that they won't be setup like this in existing software.

First of all, this isn't about WebDAV. PUT and DELETE are defined in 

Also, Content Negotiation via Accept: doesn't help here. Accept: is for 
negotiating the media type of the response, not what it describes. We 
need a different hook.

> ** You will not be able to write a form which integrates with an existing WebDAV server and has all the behaviour you would _now_ expect ***

Indeed. But it would be nice if it was possible to write a server that 
does both on the same set of URIs.

>>> Working towards a concrete proposal is the aim here. Since the bug has been closed by the editor twice before i hesitate reopening it as it seems unable to progress through this channel. Also as a substantial piece of specification i think it will require full wg attention.
>>> That we're half way through last call is fine, this has been raised as an issue for a long time and it is in response to both wg and public feedback that it has progressed to its current state. While there is work still to do, it is limited in scope and i feel we are progressing well towards the solution.
>>> I don't think browser adoption will be an issue here, chrome had some support for PUT and DELETE however since its removal from the specification i'm unsure on any current implementation. As HTML is not due for recommendation for years it seems that browser vendors will still have plenty of time to implement re-speced features.
>>> Do you suggest any other means for this to progress other than escalation to an issue?
>>> ...
>> We should try to come up with a complete proposal; as you see we aren't there yet. Once we have that, we can either try to get it into HTML5 or HTML.next, or write a separate delta spec.
>> Best regards, Julian
> Yes we should definitely continue to work on a complete proposal, my concern is what happens to the bug in that time. I am not happy leaving the bug in a RESOLVED status.
> As you noted, time is moving on and i think it will progress the faster as an issue and with full attention. If the result of the issue is to punt it on to HTML.next then that is the outcome. Personally, however, this has been a core part of HTML5 since its inception and there is no reason for it to be excluded.
> The only reason i can see for not raising it as a issue at this time is due to the implied time restrictions on proposals. This is not a concrete enforcement however.
> Maybe we can add this information to the bug report and request that it remain open pending the development of the proposal? Isn't this the point of a tracker issue tho?
> ...

You may want to consult the HTML WG's Decision Policy document for details.

Best regards, Julian
Received on Tuesday, 13 December 2011 15:10:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC