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
