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:54:01 +0000
Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
Message-Id: <734190D0-EF51-4335-90B9-E0D922AE0CB4@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>

On 13/12/2011, at 4:29 PM, Julian Reschke wrote:

> On 2011-12-13 17:09, Cameron Heavon-Jones wrote:
>> ...
>> 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?
>> ...
> 
> For instance, a UI that allows deleting resource both through a script-less form (where you need a new HTML page to be displayed as result), and a script-driven XHR based UI (where you only want to know success/fail). Note that in both cases the same user agent makes the request, but it has different requirements on the response type.

This is exactly where "Accept" should be used. Either the script should advertise it wants "text\plain" status message or maybe an "application\json" response.

> 
>>> 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.
> 
> It depends on what request header is used for negotiation.

while it is possible to vary on another header, it is not desirable. this is relatively immaterial for this discussion tho.

> 
>> You want to send different html based on who the client is. This is bad ReST, IMO.
> 
> Wrong.
> 
> I might agree if this was about GET, but it's not. What needs to be negotiated is not the media type but something else; *what* the response should represent (the status of the request, the new state of the resource, whatbot). Keep in mind that in general, the response to a request other than GET is *not* a representation of the addressed resource.
> 

yes, you are negotiating the representation. i have no problem with any of this but as a recommended practice i would not vary on anything other than "Accept" and question why a user of one html-client should see something different from a user of another html-client.

i am well aware that the response to DELETE etc does not represent the same as a GET on the resource, this is an incredibly powerful feature which is underused at present, IMO. 

a simple case where this is valuable is in replacing a 204 after delete with a 200 and providing html to a user - a request specific view and unbookmarkable.


>> ...
>>> 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.
> 
> I'm satisfied that the text that was in HTML5 back when I opened the bug has been removed, as it was causing implementations to do things they should not do.

I agree with this reasoning, i think we've moved on since.

> 
> I'm not satisfied with having no solution for PUT and DELETE, but having a proper solution in the future IMHO is much better than having a broken solution today that will be impossible to back out due to existing content relying on it.
> 

The proposal will be the only way to decide if it is a proper solution which should be implemented or not. I am more than happy to work on it even given a tentative conclusion. 


>> 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.
> 
> Best regards, Julian

Thanks,
Cam
Received on Tuesday, 13 December 2011 17:00:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 17:00:54 GMT