On 13/12/2011, at 1:30 PM, Julian Reschke wrote: > On 2011-12-13 14:10, Cameron Heavon-Jones wrote: >> >> 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. > > Yes, but that's for the format. An Accept header of > > Accept: text/html > > doesn't tell the server *what* kind of HTML content you want (a status > message vs something that could be used as a next page in a user interaction).
I think that is quite definitely Out Of Scope. If there needs to be different content for the same format this should be a different URI. > >> 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 personally think that without a complete proposal that has some chance of > getting browser adoption this has zero chance to get through, given the fact > that we are ~half a year into Last Call. > >> ... > > Best regards, Julian 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? Thanks, Cam
