On 13/12/2011, at 1:04 PM, Julian Reschke wrote: > On 2011-12-13 13:48, Cameron Heavon-Jones wrote: >> ... >>> In my mind, this may be true to some extent. For example, let's say I'm >>> browsing my blog backend, opening the latest post page, and sending a >>> successful DELETE request. If the server replies with a 204 (no content) >>> response, what should my browser do? Nothing? Redirect to post-list? >> >> There is nothing which specifies that a server *must* respond to a DELETE >> with a 204. Why is 204 deemed to be the correct response? If a server is >> communicating with a user through a html-browser it should be returning >> content for the user to see. If the server isn't currently doing that, it >> doesn't invalidate the request, it just means the server doesn't implement >> that. >> ... > > 204 is a plausible response because there's really nothing else to say when a > client requests a delete, and the served did it. > > "If a server is communicating with a user through a html-browser it should be > returning content for the user to see." > > How would it know that?
We started discussing this before and it's good to get back to it :) The standard means of content-negotiation is the Accept header. > >>> Is there a list of conflicting use-cases? What is the state of the draft >>> proposal? Can I help in some way? >>> >> >> A list of use cases and concerns to address is really useful, the work Mike >> has started contains the most up to date state of a proposal. >> >> With some further thought, instead of reopening the bug i will just request >> for it to be raised as a tracker issue as it will require the full attention >> of the working group. From there proposals are solicited as a means of >> applying changes to the specification. >> >> I hope that you and everyone else who has been involved so far will remain >> engaged in the issue and that this will progress united and with as much >> community help as can be provided. > > I think this would be premature without a complete proposal. And no, I don't > think this is going to be in HTML5, unless there'll be a big change to the > proposed timeline. > > Best regards, Julian I'm in the process of requesting this be raised as a tracker issue(s). Are you suggesting that escalating is premature before a final proposal is written? I'm currently considering 2 issues for additional form methods and the specification of response handling. Thanks, Cam
