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