Follow-up about PUT and DELETE in form methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Follow-up about PUT and DELETE in form methods

Thibault Jouannic-2
Hi,

I was looking for some news about the state of PUT and DELETE methods adoption or removal in forms.

As far as I know, the bug was reopened[1], but I don't see any definitive decision in the thread. I also noticed that some work is being done[2], but I can't find anything about the adoption of this.

Since I'm new on this list, could someone tell me where can I find the latest discussion about it, or if any decision was adopted?

Regards,
Thibault Jouannic

[1] - https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671
[2] - http://amundsen.com/examples/put-delete-forms/


Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones
On 07/12/2011, at 3:58 PM, Thibault Jouannic wrote:

> Hi,
>
> I was looking for some news about the state of PUT and DELETE methods adoption or removal in forms.
>
> As far as I know, the bug was reopened[1], but I don't see any definitive decision in the thread. I also noticed that some work is being done[2], but I can't find anything about the adoption of this.
>
> Since I'm new on this list, could someone tell me where can I find the latest discussion about it, or if any decision was adopted?
>
> Regards,
> Thibault Jouannic
>
> [1] - https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671
> [2] - http://amundsen.com/examples/put-delete-forms/
>
>

Hi Thibault,

I reopened the bug earlier this year prompted by requests from this mailing list. since we've been working on a draft proposal and also addressing concerns from Julian who initially created the bug. the most recent discussion can be found on public-html[1] which was started by yet another request to revisit.

the bug was recently closed by the editor with a resolution of WONTFIX, however the rational appears vague and recent work has not been addressed.

after waiting due time for a reply, if not forthcoming i'll reopen the bug again to request an official response from the editor.

the html wg decision making policy defines the procedure which is being followed[2].

Thanks,
Cameron Jones

[1] http://lists.w3.org/Archives/Public/public-html/2011Nov/0234.html
[2] http://dev.w3.org/html5/decision-policy/decision-policy.html
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Thibault Jouannic-2
Hi Cameron,

Thank you for your reply.

As far as I understand, the bug was closed because the editor stated that some interactions between browsers and web servers were not really defined, and that there would be conflicting use cases, in the case of a PUT or a DELETE request.

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?

Is there a list of conflicting use-cases? What is the state of the draft proposal? Can I help in some way?

Regards.
--
Thibault Jouannic
Ingénieur web freelance
+33 (0) 6 30 47 30 50
http://thibault.jouannic.fr

On Fri, 9 Dec 2011 15:14:57 +0000
Cameron Heavon-Jones <[hidden email]> wrote:

> I reopened the bug earlier this year prompted by requests from this mailing list. since we've been working on a draft proposal and also addressing concerns from Julian who initially created the bug. the most recent discussion can be found on public-html[1] which was started by yet another request to revisit.

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones
On 12/12/2011, at 9:50 AM, thibault wrote:

> Hi Cameron,
>
> Thank you for your reply.
>
> As far as I understand, the bug was closed because the editor stated that some interactions between browsers and web servers were not really defined, and that there would be conflicting use cases, in the case of a PUT or a DELETE request.

User Agent behaviour in handling response status codes is not defined in the http specification. The description of the status code does hint to an expected behaviour yet this is a matter of interpretation within the context of a UA target and any inference within a single context, while sensible, is not a mandate and can not be expected universally.

This isn't a problem with http specification or html for that matter, it's just an area which hasn't been specified before. It seems increasingly likely that html may become a harbour for this, however this is a separate issue from the application of form methods since UA processing is the same for GET and POST through forms and through any type of XHR requests.

If PUT and DELETE have highlighted another issue this is a good thing, but existing UA behaviour in response handling is no refection on the validity of form methods.

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

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


> Regards.
> --
> Thibault Jouannic
> Ingénieur web freelance
> +33 (0) 6 30 47 30 50
> http://thibault.jouannic.fr
>


Thanks,
Cameron Jones


> On Fri, 9 Dec 2011 15:14:57 +0000
> Cameron Heavon-Jones <[hidden email]> wrote:
>
>> I reopened the bug earlier this year prompted by requests from this mailing list. since we've been working on a draft proposal and also addressing concerns from Julian who initially created the bug. the most recent discussion can be found on public-html[1] which was started by yet another request to revisit.


Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
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?

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

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones

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


Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
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'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

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones

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
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
On 2011-12-13 14:50, Cameron Heavon-Jones wrote:
>> 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 disagree. If you need separate URIs to make this work, something is wrong.

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Mirko Gustony
Hello,

excuse me but,

2011/12/13 Julian Reschke <[hidden email]>:
>> 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 disagree. If you need separate URIs to make this work, something is wrong.

from my reading of [1] (and several other sources on that) Cameron
seems to be right. Different content (not different representation)
means different document and therefor different URI.

I for one would welcome a solution for bringing RESTful webservices to
HTML forms without hacks or Javascript.

Regards,
Mirko

1: <http://en.wikipedia.org/wiki/Representational_state_transfer>

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones
In reply to this post by Julian Reschke

On 13/12/2011, at 2:07 PM, Julian Reschke wrote:

> On 2011-12-13 14:50, Cameron Heavon-Jones wrote:
>>> 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 disagree. If you need separate URIs to make this work, something is wrong.

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.

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.

** 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 ***

>
>> 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?

Thanks,
Cam
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
In reply to this post by Mirko Gustony
On 2011-12-13 15:23, Mirko Gustony wrote:

> Hello,
>
> excuse me but,
>
> 2011/12/13 Julian Reschke<[hidden email]>:
>>> 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 disagree. If you need separate URIs to make this work, something is wrong.
>
> from my reading of [1] (and several other sources on that) Cameron
> seems to be right. Different content (not different representation)
> means different document and therefor different URI.

We're talking about a single resource (thus one URI), that gets a DELETE
request.

Different clients have different expectations on the response payload
they get for a successful DELETE, though. Most non-HTML clients do not
care about any additional information, so sending more than a status
message is a waste of bits.

Note that HTTP says:

"A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted) if the action has not yet
been enacted, or 204 (No Content) if the action has been enacted but the
response does not include an entity." --
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7>

So you can send a "status" page, but assuming that a server always will
do that would be incorrect because most clients will not need it.

> I for one would welcome a solution for bringing RESTful webservices to
> HTML forms without hacks or Javascript.
> ...

Yes, but please let's not replace one kind of hack with a different kind
of hack.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

mamund
Based on repeated comments about what this issue of what the browser
user-agent *expects* as a return for PUT/DELETE, I wonder if things
would go better if the Prefer header proposal was included in all
this.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Tue, Dec 13, 2011 at 10:04, Julian Reschke <[hidden email]> wrote:

> On 2011-12-13 15:23, Mirko Gustony wrote:
>>
>> Hello,
>>
>> excuse me but,
>>
>> 2011/12/13 Julian Reschke<[hidden email]>:
>>
>>>> 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 disagree. If you need separate URIs to make this work, something is
>>> wrong.
>>
>>
>> from my reading of [1] (and several other sources on that) Cameron
>> seems to be right. Different content (not different representation)
>> means different document and therefor different URI.
>
>
> We're talking about a single resource (thus one URI), that gets a DELETE
> request.
>
> Different clients have different expectations on the response payload they
> get for a successful DELETE, though. Most non-HTML clients do not care about
> any additional information, so sending more than a status message is a waste
> of bits.
>
> Note that HTTP says:
>
> "A successful response SHOULD be 200 (OK) if the response includes an entity
> describing the status, 202 (Accepted) if the action has not yet been
> enacted, or 204 (No Content) if the action has been enacted but the response
> does not include an entity." --
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7>
>
> So you can send a "status" page, but assuming that a server always will do
> that would be incorrect because most clients will not need it.
>
>> I for one would welcome a solution for bringing RESTful webservices to
>> HTML forms without hacks or Javascript.
>> ...
>
>
> Yes, but please let's not replace one kind of hack with a different kind of
> hack.
>
> Best regards, Julian
>

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
In reply to this post by cameronjones
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

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones
In reply to this post by Julian Reschke

On 13/12/2011, at 3:04 PM, Julian Reschke wrote:

> Different clients have different expectations on the response payload they get for a successful DELETE, though. Most non-HTML clients do not care about any additional information, so sending more than a status message is a waste of bits.

Why is the client advertising that it "Accept: text\html" if it doesn't want it? Seems like it is requesting a waste of bits.

if it wants a simple status message it should "Accept: text\plain" or some such other.

thanks,
cam
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

cameronjones
In reply to this post by mamund

On 13/12/2011, at 3:09 PM, mike amundsen wrote:

> Based on repeated comments about what this issue of what the browser
> user-agent *expects* as a return for PUT/DELETE, I wonder if things
> would go better if the Prefer header proposal was included in all
> this.
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>

Personally i don't agree with "Prefer" header but i stated this previously, as it is optional i just choose not to use it.

If it satisfies concerns i have no problem referencing it as something people can use.

Thanks,
Cam
Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
In reply to this post by mamund
On 2011-12-13 16:09, mike amundsen wrote:
> Based on repeated comments about what this issue of what the browser
> user-agent *expects* as a return for PUT/DELETE, I wonder if things
> would go better if the Prefer header proposal was included in all
> this.
> ...

Absolutely.

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
In reply to this post by cameronjones
On 2011-12-13 16:16, Cameron Heavon-Jones wrote:

>
> On 13/12/2011, at 3:09 PM, mike amundsen wrote:
>
>> Based on repeated comments about what this issue of what the browser
>> user-agent *expects* as a return for PUT/DELETE, I wonder if things
>> would go better if the Prefer header proposal was included in all
>> this.
>>
>> mca
>> http://amundsen.com/blog/
>> http://twitter.com@mamund
>> http://mamund.com/foaf.rdf#me
>>
>
> Personally i don't agree with "Prefer" header but i stated this previously, as it is optional i just choose not to use it.
>
> If it satisfies concerns i have no problem referencing it as something people can use.

Well, to make this "work", we'd need to define a Preference token, and
mandate that the browser sends it.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

Julian Reschke
In reply to this post by cameronjones
On 2011-12-13 16:13, Cameron Heavon-Jones wrote:
>
> On 13/12/2011, at 3:04 PM, Julian Reschke wrote:
>
>> Different clients have different expectations on the response payload they get for a successful DELETE, though. Most non-HTML clients do not care about any additional information, so sending more than a status message is a waste of bits.
>
> Why is the client advertising that it "Accept: text\html" if it doesn't want it? Seems like it is requesting a waste of bits.
>
> if it wants a simple status message it should "Accept: text\plain" or some such other.

If everything was written from scratch, maybe. But it isn't.

Servers have sent HTML-typed status messages for over a decade now, and
the HTTP spec even recommends it in several places.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Follow-up about PUT and DELETE in form methods

mamund
In reply to this post by Julian Reschke
following along my original approach of adding attributes to HTML.FORM
that are converted to HTTP Headers[1], the HTML.FORM@prefer could be
included, too.  This would mean servers need to decide how to deal w/
this situation, too.

[1] http://amundsen.com/examples/put-delete-forms/#added-attributes

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Tue, Dec 13, 2011 at 10:24, Julian Reschke <[hidden email]> wrote:

> On 2011-12-13 16:16, Cameron Heavon-Jones wrote:
>>
>>
>> On 13/12/2011, at 3:09 PM, mike amundsen wrote:
>>
>>> Based on repeated comments about what this issue of what the browser
>>> user-agent *expects* as a return for PUT/DELETE, I wonder if things
>>> would go better if the Prefer header proposal was included in all
>>> this.
>>>
>>> mca
>>> http://amundsen.com/blog/
>>> http://twitter.com@mamund
>>> http://mamund.com/foaf.rdf#me
>>>
>>
>> Personally i don't agree with "Prefer" header but i stated this
>> previously, as it is optional i just choose not to use it.
>>
>> If it satisfies concerns i have no problem referencing it as something
>> people can use.
>
>
> Well, to make this "work", we'd need to define a Preference token, and
> mandate that the browser sends it.
>
> Best regards, Julian

123