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

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

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Tue, 13 Dec 2011 16:09:06 +0000
Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
Message-Id: <963DC8BE-9DCD-4CE8-8BEA-8F1A9DBE9676@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>

On 13/12/2011, at 3:10 PM, Julian Reschke wrote:

> 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!

Agreed! 

> 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.

Yes, the requests will need to be different in order to send different responses. Accept header is a request variation, just pointing that out.

> 
>> 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 HTTP/1.1
> 

Let's leave WebDAV alone. What is the use case we're discussing then if not how WebDAV servers return a status message for WebDAV client and full html representation for browsers over the same "Accept" header? 

> 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.

Content negotiation is a valid (and the only) way for determining whether to send html or not.

You want to send different html based on who the client is. This is bad ReST, IMO.

> 
>> ** 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.

Yes, this it is possible to write a server to do this, existing servers will not be setup for this of course.

> 
>>>> 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


The decision policy is not definitive in this regard, i was trying to solicit some common consensus on the best way to proceed in the interests of this case and contributors. 

My opinion is that this is only going to progress as a tracker issue. i assume that your opinion is that the bug should remain RESOLVED WONTFIX as you opened the bug and are no doubt satisfied with the current status, for the time being.

this leaves me in the position of requiring this to be escalated to ensure it is addressed within HTML5. i have not heard anything which changes my opinion on this and hence will request a tracker issue unless there is some reasoned objection and suggestion of an alternative path.

Thanks,
Cam
Received on Tuesday, 13 December 2011 19:56:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 19:56:22 GMT