On 2011-12-13 15:25, Cameron Heavon-Jones wrote:
...
It's not a question of 'getting it to work', it is a question of whether it is
correct to assume that the same request should result in two different
responses - that is wrong.
...
No, the same request should indeed result in the same response! Of course!
So if we want servers to be able to continue to return 204 on DELETE,
but also want to enable servers to send a rich HTML page to browsers,
we'd need to make the requests different.
unfortunately we're discussing specific implementations - a WebDAV server. This
isn't even spec'd WebDAV behaviour, it's just what current servers are doing.
There is no foundation to expect existing services to magically just start
integrating with new clients. WebDAV servers are written for WebDAV clients,
not HTML browser clients. Servers *CAN* be written to support both with
content-negotation, it's just that they won't be setup like this in existing
software.
First of all, this isn't about WebDAV. PUT and DELETE are defined in
HTTP/1.1
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.
** You will not be able to write a form which integrates with an existing
WebDAV server and has all the behaviour you would _now_ expect ***
Indeed. But it would be nice if it was possible to write a server that
does both on the same set of URIs.
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?
...
We should try to come up with a complete proposal; as you see we aren't there
yet. Once we have that, we can either try to get it into HTML5 or HTML.next, or
write a separate delta spec.
Best regards, Julian
Yes we should definitely continue to work on a complete proposal, my concern is
what happens to the bug in that time. I am not happy leaving the bug in a
RESOLVED status.
As you noted, time is moving on and i think it will progress the faster as an
issue and with full attention. If the result of the issue is to punt it on to
HTML.next then that is the outcome. Personally, however, this has been a core
part of HTML5 since its inception and there is no reason for it to be excluded.
The only reason i can see for not raising it as a issue at this time is due to
the implied time restrictions on proposals. This is not a concrete enforcement
however.
Maybe we can add this information to the bug report and request that it remain
open pending the development of the proposal? Isn't this the point of a tracker
issue tho?
...
You may want to consult the HTML WG's Decision Policy document for details.
Best regards, Julian
