[Fwd: Re: PUT and DELETE methods in 200 code]

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

[Fwd: Re: PUT and DELETE methods in 200 code]

Nathan Rixham-2
fwd'ing to some relevant lists - would be very happy to see a proper
response from W3C / HTML WG chairs, particularly the question "And
*where* should this activity happen?"

best, nathan

-------- Original Message --------
Subject: Re: PUT and DELETE methods in 200 code
Resent-Date: Fri, 01 Apr 2011 13:45:27 +0000
Resent-From: [hidden email]
Date: Fri, 1 Apr 2011 09:41:52 -0400
From: mike amundsen <[hidden email]>
To: Julian Reschke <[hidden email]>
CC: Dominik Tomaszuk <[hidden email]>, [hidden email]
References: <[hidden email]> <[hidden email]>

I see the bug has been re-opened.

I see there has been some discussion on public-html-comments regarding
PUT/DELETE[1].
I also note at least one suggestion in that thread was to discuss this
on the whatwg list[2].

What is the preferred way to proceed here?
- List concerns/reservations and deal with them as they come up?
- Draw up a straw man proposal (is there a standard format for this)?
- Some other process?

And *where* should this activity happen?
- here
- public-html-comments
- whatwg
- buglist
- etc.

[1]
http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/thread.html
[2]
http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/0026.html

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


#RESTFest 2010
http://rest-fest.googlecode.com




On Wed, Mar 30, 2011 at 10:31, Julian Reschke <[hidden email]> wrote:

> On 30.03.2011 16:02, Dominik Tomaszuk wrote:
>>
>> Hi all,
>>
>> In [1] there are specified HTTP methods in 200 code. I think that this
>> section should be extended to PUT and DELETE methods, because in [2] and
>> [3] authors write references to 200 code [1]. In my opinion PUT and
>> DELETE methods can be defined the same as POST (a representation
>> describing or containing the result of the action). It could be very
>> helpful especially for RESTful applications.
>>
>> [1]
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.2.1
>> [2]
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.6
>> [3]
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.7
>>
>> Regards,
>>
>> Dominik Tomaszuk
>
> Hi Dominik,
>
> thanks for coming over here to discuss this.
>
> Let's have a look at PUT. Three things that come to mind what a 200 response
> could carry are:
>
> - nothing (the server did what you asked for, and that's really all you need
> to know) -- this is what many (most) WebDAV servers will do
>
> - return a small status message
>
> - return the new representation of the resource
>
> There are probably more options. I'm not sure the HTTP spec can/should
> mandate any.
>
> So also recent discussion of "Prefer"...: starting at
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0291.html>.
>
> BR, Julian
>
>




Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Sam Ruby-2
On 04/01/2011 02:01 PM, Nathan wrote:
> fwd'ing to some relevant lists - would be very happy to see a proper
> response from W3C / HTML WG chairs, particularly the question "And
> *where* should this activity happen?"

Where is in bug reports:

http://dev.w3.org/html5/decision-policy/decision-policy.html

Should you (or anyone) wish to escalate a proposed RESOLUTION by the
editor, you will be encouraged to join the working group and participate
by creating a proposal and participating in the discussion:

http://www.w3.org/html/wg/#join

> best, nathan

- Sam Ruby

> -------- Original Message --------
> Subject: Re: PUT and DELETE methods in 200 code
> Resent-Date: Fri, 01 Apr 2011 13:45:27 +0000
> Resent-From: [hidden email]
> Date: Fri, 1 Apr 2011 09:41:52 -0400
> From: mike amundsen <[hidden email]>
> To: Julian Reschke <[hidden email]>
> CC: Dominik Tomaszuk <[hidden email]>, [hidden email]
> References: <[hidden email]> <[hidden email]>
>
> I see the bug has been re-opened.
>
> I see there has been some discussion on public-html-comments regarding
> PUT/DELETE[1].
> I also note at least one suggestion in that thread was to discuss this
> on the whatwg list[2].
>
> What is the preferred way to proceed here?
> - List concerns/reservations and deal with them as they come up?
> - Draw up a straw man proposal (is there a standard format for this)?
> - Some other process?
>
> And *where* should this activity happen?
> - here
> - public-html-comments
> - whatwg
> - buglist
> - etc.
>
> [1]
> http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/thread.html
>
> [2]
> http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/0026.html
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>
>
> #RESTFest 2010
> http://rest-fest.googlecode.com
>
>
>
>
> On Wed, Mar 30, 2011 at 10:31, Julian Reschke <[hidden email]>
> wrote:
>> On 30.03.2011 16:02, Dominik Tomaszuk wrote:
>>>
>>> Hi all,
>>>
>>> In [1] there are specified HTTP methods in 200 code. I think that this
>>> section should be extended to PUT and DELETE methods, because in [2] and
>>> [3] authors write references to 200 code [1]. In my opinion PUT and
>>> DELETE methods can be defined the same as POST (a representation
>>> describing or containing the result of the action). It could be very
>>> helpful especially for RESTful applications.
>>>
>>> [1]
>>>
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.2.1
>>>
>>> [2]
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.6
>>>
>>> [3]
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.7
>>>
>>>
>>> Regards,
>>>
>>> Dominik Tomaszuk
>>
>> Hi Dominik,
>>
>> thanks for coming over here to discuss this.
>>
>> Let's have a look at PUT. Three things that come to mind what a 200
>> response
>> could carry are:
>>
>> - nothing (the server did what you asked for, and that's really all
>> you need
>> to know) -- this is what many (most) WebDAV servers will do
>>
>> - return a small status message
>>
>> - return the new representation of the resource
>>
>> There are probably more options. I'm not sure the HTTP spec can/should
>> mandate any.
>>
>> So also recent discussion of "Prefer"...: starting at
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0291.html>.
>>
>> BR, Julian
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Julian Reschke
On 01.04.2011 21:04, Sam Ruby wrote:

> On 04/01/2011 02:01 PM, Nathan wrote:
>> fwd'ing to some relevant lists - would be very happy to see a proper
>> response from W3C / HTML WG chairs, particularly the question "And
>> *where* should this activity happen?"
>
> Where is in bug reports:
>
> http://dev.w3.org/html5/decision-policy/decision-policy.html
>
> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
> editor, you will be encouraged to join the working group and participate
> by creating a proposal and participating in the discussion:
>
> http://www.w3.org/html/wg/#join
>
>> best, nathan
>
> - Sam Ruby

I'm currently interested in a discussion that leads to something that
*could* be added to the HTML spec, and might lead to clarifications in
the HTTPbis specs.

I don't think an issue tracker is the right place for that.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Sam Ruby-2
On 04/01/2011 03:29 PM, Julian Reschke wrote:

> On 01.04.2011 21:04, Sam Ruby wrote:
>> On 04/01/2011 02:01 PM, Nathan wrote:
>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>> response from W3C / HTML WG chairs, particularly the question "And
>>> *where* should this activity happen?"
>>
>> Where is in bug reports:
>>
>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>
>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>> editor, you will be encouraged to join the working group and participate
>> by creating a proposal and participating in the discussion:
>>
>> http://www.w3.org/html/wg/#join
>>
>>> best, nathan
>>
>> - Sam Ruby
>
> I'm currently interested in a discussion that leads to something that
> *could* be added to the HTML spec, and might lead to clarifications in
> the HTTPbis specs.
>
> I don't think an issue tracker is the right place for that.

In that case, discussions can happen anywhere; but those that could lead
to changes to the W3C HTML spec should occur on public-html to ensure
that all of the right people see it.

> Best regards, Julian

- Sam Ruby


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

mamund
Cross-posting to related groups:

I've posted a document[1] that shows one way in which HTML FORMS can
support PUT/DELETE w/o the need for plug-ins or scripting. It's a
quick draft but I think it covers the basics.

If this is not in the desired format let me know.


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

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


#RESTFest 2010
http://rest-fest.googlecode.com




On Fri, Apr 1, 2011 at 16:24, Sam Ruby <[hidden email]> wrote:

> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>
>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>
>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>
>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>> *where* should this activity happen?"
>>>
>>> Where is in bug reports:
>>>
>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>
>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>> editor, you will be encouraged to join the working group and participate
>>> by creating a proposal and participating in the discussion:
>>>
>>> http://www.w3.org/html/wg/#join
>>>
>>>> best, nathan
>>>
>>> - Sam Ruby
>>
>> I'm currently interested in a discussion that leads to something that
>> *could* be added to the HTML spec, and might lead to clarifications in
>> the HTTPbis specs.
>>
>> I don't think an issue tracker is the right place for that.
>
> In that case, discussions can happen anywhere; but those that could lead to
> changes to the W3C HTML spec should occur on public-html to ensure that all
> of the right people see it.
>
>> Best regards, Julian
>
> - Sam Ruby
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Subbu Allamaraju-2
Do you need the conditional headers as form parameters? The agent should be able to replay those headers.

Subbu

On Apr 1, 2011, at 5:50 PM, mike amundsen wrote:

> Cross-posting to related groups:
>
> I've posted a document[1] that shows one way in which HTML FORMS can
> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
> quick draft but I think it covers the basics.
>
> If this is not in the desired format let me know.
>
>
> [1] http://amundsen.com/examples/put-delete-forms/
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>
>
> #RESTFest 2010
> http://rest-fest.googlecode.com
>
>
>
>
> On Fri, Apr 1, 2011 at 16:24, Sam Ruby <[hidden email]> wrote:
>> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>>
>>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>>
>>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>>
>>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>>> *where* should this activity happen?"
>>>>
>>>> Where is in bug reports:
>>>>
>>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>>
>>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>>> editor, you will be encouraged to join the working group and participate
>>>> by creating a proposal and participating in the discussion:
>>>>
>>>> http://www.w3.org/html/wg/#join
>>>>
>>>>> best, nathan
>>>>
>>>> - Sam Ruby
>>>
>>> I'm currently interested in a discussion that leads to something that
>>> *could* be added to the HTML spec, and might lead to clarifications in
>>> the HTTPbis specs.
>>>
>>> I don't think an issue tracker is the right place for that.
>>
>> In that case, discussions can happen anywhere; but those that could lead to
>> changes to the W3C HTML spec should occur on public-html to ensure that all
>> of the right people see it.
>>
>>> Best regards, Julian
>>
>> - Sam Ruby
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

mamund
Subbu:

Not sure of your question, so I'll take a shot:

*** You might be asking if the conditional header should be present in
the body at all.
Consider cases where the response contains a list of possible
resources to PUT/DELETE, each possibility rendered as a FORM with the
response representation:

<html>
...
<h1>Unresolved Orders</h1>
<form action="..." method="delete" if-match="q1w2e3"><label>Order
#123</label><input type="submit" value="delete" /></form>
<form action="..." method="delete" if-match="w2e3r4"><label>Order
#456</label><input type="submit" value="delete" /></form>
<form action="..." method="delete" if-match="e3r4t5"><label>Order
#789</label><input type="submit" value="delete" /></form>
...
</html>

In the above example, the Etag of the response representation would be
insufficient as that Etag belongs to the entire response, not any of
the resources represented by each form in the body.


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


#RESTFest 2010
http://rest-fest.googlecode.com




On Fri, Apr 1, 2011 at 21:07, Subbu Allamaraju <[hidden email]> wrote:

> Do you need the conditional headers as form parameters? The agent should be able to replay those headers.
>
> Subbu
>
> On Apr 1, 2011, at 5:50 PM, mike amundsen wrote:
>
>> Cross-posting to related groups:
>>
>> I've posted a document[1] that shows one way in which HTML FORMS can
>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
>> quick draft but I think it covers the basics.
>>
>> If this is not in the desired format let me know.
>>
>>
>> [1] http://amundsen.com/examples/put-delete-forms/
>>
>> mca
>> http://amundsen.com/blog/
>> http://twitter.com@mamund
>> http://mamund.com/foaf.rdf#me
>>
>>
>> #RESTFest 2010
>> http://rest-fest.googlecode.com
>>
>>
>>
>>
>> On Fri, Apr 1, 2011 at 16:24, Sam Ruby <[hidden email]> wrote:
>>> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>>>
>>>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>>>
>>>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>>>
>>>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>>>> *where* should this activity happen?"
>>>>>
>>>>> Where is in bug reports:
>>>>>
>>>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>>>
>>>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>>>> editor, you will be encouraged to join the working group and participate
>>>>> by creating a proposal and participating in the discussion:
>>>>>
>>>>> http://www.w3.org/html/wg/#join
>>>>>
>>>>>> best, nathan
>>>>>
>>>>> - Sam Ruby
>>>>
>>>> I'm currently interested in a discussion that leads to something that
>>>> *could* be added to the HTML spec, and might lead to clarifications in
>>>> the HTTPbis specs.
>>>>
>>>> I don't think an issue tracker is the right place for that.
>>>
>>> In that case, discussions can happen anywhere; but those that could lead to
>>> changes to the W3C HTML spec should occur on public-html to ensure that all
>>> of the right people see it.
>>>
>>>> Best regards, Julian
>>>
>>> - Sam Ruby
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Arthur Clifford
I realize this may be heresy, but why is using PUT and DELETE appropriate? And why should HTML 5 or any version of HTML be considered an application development language rather than a hyper-text markup language?

I would argue that the nuance of post and has historically been blurred since GET pretty much meant a CGI URL and thus had a character limit while POST was unlimited. So many of us in the field just stuck with POST even for GET operations when user input, or number of parameters went past that limit.

Frankly, I think that the user agent requesting content via a URL should be required to do a GET, and that Forms should be required to POST, and that the method attribute be done away with to avoid confusion. REST is just remote proceedure calls. I think that PHP's superglobal $_REQUEST shows the practical perspective of things; no matter what you are doing it is just a request that you are providing parameters to. I don't think the industry standard should change to reflect an academic presumption that the HTTP POST, DELETE, GET, and PUT are "the right way" to do post parameters to a remote procedure call. There needs to be a distinction between the transfer protocol (HTTP) and the the functionality of the remote procedure calls.

Furthermore there are nuances to GET and POST that aren't as obscure as those referenced so far in this thread. Safari, for instance, when you do GET operations even via HTTPS displays the URLS that are accessed in its Activity window in clear text. Even if you are getting content via HTTPs you need to post the parameters in order to have them encrypted. I think that is where the distinction of protocol vs remote procedure call methodology is most distinct. HTTP crud operations should NOT be used for RPC methods and they should not be confused. If REST developers, and I am one, want to distinguish between put,get, update, and delete they can create REST scripts for doing that and it would take less effort that it would to refactor the entire industry. This issue is not an HTML nor an HTTP issue is it a server-side REST API issue.

That's my heretical 2-cents,

Art



On Apr 1, 2011, at 6:33 PM, mike amundsen wrote:

> Subbu:
>
> Not sure of your question, so I'll take a shot:
>
> *** You might be asking if the conditional header should be present in
> the body at all.
> Consider cases where the response contains a list of possible
> resources to PUT/DELETE, each possibility rendered as a FORM with the
> response representation:
>
> <html>
> ...
> <h1>Unresolved Orders</h1>
> <form action="..." method="delete" if-match="q1w2e3"><label>Order
> #123</label><input type="submit" value="delete" /></form>
> <form action="..." method="delete" if-match="w2e3r4"><label>Order
> #456</label><input type="submit" value="delete" /></form>
> <form action="..." method="delete" if-match="e3r4t5"><label>Order
> #789</label><input type="submit" value="delete" /></form>
> ...
> </html>
>
> In the above example, the Etag of the response representation would be
> insufficient as that Etag belongs to the entire response, not any of
> the resources represented by each form in the body.
>
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>
>
> #RESTFest 2010
> http://rest-fest.googlecode.com
>
>
>
>
> On Fri, Apr 1, 2011 at 21:07, Subbu Allamaraju <[hidden email]> wrote:
>> Do you need the conditional headers as form parameters? The agent should be able to replay those headers.
>>
>> Subbu
>>
>> On Apr 1, 2011, at 5:50 PM, mike amundsen wrote:
>>
>>> Cross-posting to related groups:
>>>
>>> I've posted a document[1] that shows one way in which HTML FORMS can
>>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
>>> quick draft but I think it covers the basics.
>>>
>>> If this is not in the desired format let me know.
>>>
>>>
>>> [1] http://amundsen.com/examples/put-delete-forms/
>>>
>>> mca
>>> http://amundsen.com/blog/
>>> http://twitter.com@mamund
>>> http://mamund.com/foaf.rdf#me
>>>
>>>
>>> #RESTFest 2010
>>> http://rest-fest.googlecode.com
>>>
>>>
>>>
>>>
>>> On Fri, Apr 1, 2011 at 16:24, Sam Ruby <[hidden email]> wrote:
>>>> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>>>>
>>>>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>>>>
>>>>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>>>>
>>>>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>>>>> *where* should this activity happen?"
>>>>>>
>>>>>> Where is in bug reports:
>>>>>>
>>>>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>>>>
>>>>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>>>>> editor, you will be encouraged to join the working group and participate
>>>>>> by creating a proposal and participating in the discussion:
>>>>>>
>>>>>> http://www.w3.org/html/wg/#join
>>>>>>
>>>>>>> best, nathan
>>>>>>
>>>>>> - Sam Ruby
>>>>>
>>>>> I'm currently interested in a discussion that leads to something that
>>>>> *could* be added to the HTML spec, and might lead to clarifications in
>>>>> the HTTPbis specs.
>>>>>
>>>>> I don't think an issue tracker is the right place for that.
>>>>
>>>> In that case, discussions can happen anywhere; but those that could lead to
>>>> changes to the W3C HTML spec should occur on public-html to ensure that all
>>>> of the right people see it.
>>>>
>>>>> Best regards, Julian
>>>>
>>>> - Sam Ruby
>>>>
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Julian Reschke
In reply to this post by mamund
On 02.04.2011 02:50, mike amundsen wrote:

> Cross-posting to related groups:
>
> I've posted a document[1] that shows one way in which HTML FORMS can
> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
> quick draft but I think it covers the basics.
>
> If this is not in the desired format let me know.
>
>
> [1] http://amundsen.com/examples/put-delete-forms/
> ...

Mike,

thanks for getting this started.

I think it's essential to think this through completely, not to rush it.

In the meantime I recalled the main reason why I got nervous about what
the FF4 beta implemented; it adopted the broken XHR behavior for
following redirects (rewriting the request method to GET), and it also
had the URI encoding for one of the methods wrong.

Now looking at your proposal:

> Summary
>
> A proposal for supporting PUT and DELETE in HTML5 Forms.
> Goals
>
> Support for PUT/DELETE should be:
>
>     as complete as possible (per HTTP[cite] spec)
>     as seamless as possible (per current Browser behaviors)
>     easy to use via HTML (for both servers to emit and browser to process)
>     not introduce any new security problems
>     not veer substantially from support for PUT/DELETE via XHR

Personally I'd add "should integrate well with servers which already
support PUT and DELETE, such as WebDAV servers"

> Assumptions
>
> This proposal assumes:
>
>     Any controls that are currently valid for FORMs with the method=”post” are also valid for FORMs with the method=”put.”
>     Any enc-type values that are currently valid for FORMs with the method=”post” are also valid for FORMs with the method=”put.”
>     All controls and enc-type values are ignored for FORMs with the method=”delete.”

Will we need additional enc-types? Maybe something for JSON?

> A Simple HTML Example
>
> <form action=”http://example.org/user/123” method=”put” if-match=”*”>
>
>  <input name=”user-name” type=”text” value=”” />
>
>  <input name=”hat-size” type=”text” value=”” />
>
>  <input type=”submit” />
>
> </form>
>
> Filling the “user-name” and “hat-size” inputs with “mike” and “small” respectively, will result in the following HTTP request:
>
> PUT /user/123 HTTP/1.1
>
> Host: example.org
>
> Content-Type: application/x-www-form-urlencoded
>
> If-Match: *
>
> ...
>
> user-name=mike&hat-size=small

It would be good to have an example that uses non-ASCII characters.

> Added Attributes for the FORM element
>
> The following OPTIONAL attributes SHOULD be supported for the FORM element. Valid values for these new attributes MUST be the same as those outlined in the HTTP spec[cite].
> If-Match
> ...

That might be hard to swallow for some (that said, I currently don't
have a better idea *if* we want to add this kind of control).

> Below are example usage scenarios for PUT and DELETE w/ HTML Forms.
>
>     Creating a new resource
>     Editing an existing resource
>     Deleting and existing resource
>
> Creating a new resource
>
> PUT can be used to create a new resource on the server.
>
> *** REQUEST
> GET /users/;create HTTP/1.1
>
> Host: www.example.org
>
> ...
>
> *** RESPONSE
> 200 OK HTTP/1.1
>
> ...
>
> <html>
>
> ...
>
> <form action=”http://www.example.org/users/123” method=”put” if-none-match=”*”>
>
>  <input name=”user-name” value=”” />
>
>  <input name=”hat-size” value=”” />
>
>  <input type=”submit” />
>
> </form>
>
> ...
>
> </html>

If we wanted to make the user # a variable instead of hardwiring it into
the action attribute, we'd need to make it a URI template, right?

> *** REQUEST
>
> PUT /users/123 HTTP/1.1
>
> Host: www.example.org
>
> If-None-Match: *
>
> Content-Type: application/x-www-form-urlencoded
>
> Content-Length: nnn
>
> user-name=mike&hat-size=small
>
> *** RESPONSE
>
> 200 OK HTTP/1.1
>
> ...
>
> <html>
>
> ...
>
> <ul>
>
>  <li>user-name: mike</li>
>
>  <li>hat-size: small</li>
>
> </ul>
>
> ...
>
> <html>

This makes the assumption that a sender of a PUT request always is
interested in a response body that describes the new state, which is
most certainly *not* what most current implementations of PUT do.

Somebody mentioned that this could be handled using "Accept:", but I'm
not entirely sure this will work well. An alternative would be using
something like what James Snell describes in
<http://trac.tools.ietf.org/html/draft-snell-http-prefer-03#section-5>.

(The same of course applies to DELETE)

> Updating an Existing Resource
>
> PUT can be used to update/replace an existing resource
>
> *** REQUEST
> GET /users/123 HTTP/1.1
>
> Host: www.example.org
>
> ...
>
> *** RESPONSE
> 200 OK HTTP/1.1
>
> ...
>
> <html>
>
> ...
>
> <form action=”http://www.example.org/users/123” method=”put” if-match=”q1w2e3r4t5”>
>
>  <input name=”user-name” value=”” />
>
>  <input name=”hat-size” value=”” />
>
>  <input type=”submit” />
>
> </form>
>
> ...
>
> </html>
>
> *** REQUEST
>
> PUT /users/123 HTTP/1.1
>
> Host: www.example.org
>
> If-Match: q1w2e3r4t5

Nit: that is not a valid ETag; it needs to be in double quotes (in the
HTML as well, so we can also use weak etags).

> ...

> Other Considerations
>
> Below are other items for consideration.
> Handling Responses
>
> Typical responses from PUT (200/201/204) and DELETE (200/202/204) SHOULD be handled the same way these responses are handled for POST[cite].

How *are* they handled by UAs? (Is this in HTML5?).

> ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

mamund
Julian:

My comments inline....

On Sat, Apr 2, 2011 at 05:50, Julian Reschke <[hidden email]> wrote:

> On 02.04.2011 02:50, mike amundsen wrote:
>>
>> Cross-posting to related groups:
>>
>> I've posted a document[1] that shows one way in which HTML FORMS can
>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
>> quick draft but I think it covers the basics.
>>
>> If this is not in the desired format let me know.
>>
>>
>> [1] http://amundsen.com/examples/put-delete-forms/
>> ...
>
> Mike,
>
> thanks for getting this started.
>
> I think it's essential to think this through completely, not to rush it.

I agree. we've gone w/o PUT/DELETE in HTML for more than a decade,
working this through slowly doesn't add any hardship<g>.

>
> In the meantime I recalled the main reason why I got nervous about what the
> FF4 beta implemented; it adopted the broken XHR behavior for following
> redirects (rewriting the request method to GET), and it also had the URI
> encoding for one of the methods wrong.
>
> Now looking at your proposal:
>
>> Summary
>>
>> A proposal for supporting PUT and DELETE in HTML5 Forms.
>> Goals
>>
>> Support for PUT/DELETE should be:
>>
>>    as complete as possible (per HTTP[cite] spec)
>>    as seamless as possible (per current Browser behaviors)
>>    easy to use via HTML (for both servers to emit and browser to process)
>>    not introduce any new security problems
>>    not veer substantially from support for PUT/DELETE via XHR
>
> Personally I'd add "should integrate well with servers which already support
> PUT and DELETE, such as WebDAV servers"

sounds ok.

>
>> Assumptions
>>
>> This proposal assumes:
>>
>>    Any controls that are currently valid for FORMs with the method=”post”
>> are also valid for FORMs with the method=”put.”
>>    Any enc-type values that are currently valid for FORMs with the
>> method=”post” are also valid for FORMs with the method=”put.”
>>    All controls and enc-type values are ignored for FORMs with the
>> method=”delete.”
>
> Will we need additional enc-types? Maybe something for JSON?
PUT certainly doesn't *require* it, but if the WG wants to use PUT as
a "stalking horse" to expand the range of enc-types supported by HTML,
that's fine w/ me. If we go down that road, i suspect XML should also
be added as an enc-type, too.

>
>> A Simple HTML Example
>>
>> <form action=”http://example.org/user/123” method=”put” if-match=”*”>
>>
>>  <input name=”user-name” type=”text” value=”” />
>>
>>  <input name=”hat-size” type=”text” value=”” />
>>
>>  <input type=”submit” />
>>
>> </form>
>>
>> Filling the “user-name” and “hat-size” inputs with “mike” and “small”
>> respectively, will result in the following HTTP request:
>>
>> PUT /user/123 HTTP/1.1
>>
>> Host: example.org
>>
>> Content-Type: application/x-www-form-urlencoded
>>
>> If-Match: *
>>
>> ...
>>
>> user-name=mike&hat-size=small
>
> It would be good to have an example that uses non-ASCII characters.
I'll add an example using multipart, too.

>
>> Added Attributes for the FORM element
>>
>> The following OPTIONAL attributes SHOULD be supported for the FORM
>> element. Valid values for these new attributes MUST be the same as those
>> outlined in the HTTP spec[cite].
>> If-Match
>> ...
>
> That might be hard to swallow for some (that said, I currently don't have a
> better idea *if* we want to add this kind of control).
Yep. this is, IMO, the key functionality missing in HTML today that
(without it) makes PUT/DELETE unworkable for most situations. There
are some alternatives such as
- never sending them (will likely break w/ many existing servers,
teaches bad habits, can result in the lost update problem)
- always send "*" under the covers (there's a problem w/ PUT since
PUT(create) expects "if-none-match" & PUT(update) expects "if-match")
- adopt a non-protocol-specific model
(method="get|post|update|create|delete" concurrency="w/aqswde")
- there may be others

>
>> Below are example usage scenarios for PUT and DELETE w/ HTML Forms.
>>
>>    Creating a new resource
>>    Editing an existing resource
>>    Deleting and existing resource
>>
>> Creating a new resource
>>
>> PUT can be used to create a new resource on the server.
>>
>> *** REQUEST
>> GET /users/;create HTTP/1.1
>>
>> Host: www.example.org
>>
>> ...
>>
>> *** RESPONSE
>> 200 OK HTTP/1.1
>>
>> ...
>>
>> <html>
>>
>> ...
>>
>> <form action=”http://www.example.org/users/123” method=”put”
>> if-none-match=”*”>
>>
>>  <input name=”user-name” value=”” />
>>
>>  <input name=”hat-size” value=”” />
>>
>>  <input type=”submit” />
>>
>> </form>
>>
>> ...
>>
>> </html>
>
> If we wanted to make the user # a variable instead of hardwiring it into the
> action attribute, we'd need to make it a URI template, right?
Templates are an option (although the I-D is still in flux there,
right?). I suspect this is primarily interesting in the PUT(create)
case as PUT(update) and DELETE can easily get complete URIs. HTML
adopted the pattern of encoding INPUT values into the URI for GET and
into the body for POST. Seems awkward to "mix" these two behaviors for
PUT/DELETE, but I'm open to exploring support for URI Templates in
HTML.

>
>> *** REQUEST
>>
>> PUT /users/123 HTTP/1.1
>>
>> Host: www.example.org
>>
>> If-None-Match: *
>>
>> Content-Type: application/x-www-form-urlencoded
>>
>> Content-Length: nnn
>>
>> user-name=mike&hat-size=small
>>
>> *** RESPONSE
>>
>> 200 OK HTTP/1.1
>>
>> ...
>>
>> <html>
>>
>> ...
>>
>> <ul>
>>
>>  <li>user-name: mike</li>
>>
>>  <li>hat-size: small</li>
>>
>> </ul>
>>
>> ...
>>
>> <html>
>
> This makes the assumption that a sender of a PUT request always is
> interested in a response body that describes the new state, which is most
> certainly *not* what most current implementations of PUT do.
>
> Somebody mentioned that this could be handled using "Accept:", but I'm not
> entirely sure this will work well. An alternative would be using something
> like what James Snell describes in
> <http://trac.tools.ietf.org/html/draft-snell-http-prefer-03#section-5>.
Yeah, Snell's notion seems closer to what might be desireable. Of
course, having agent add a new (optional) header will not likely
improve the results from any existing servers.

>
> (The same of course applies to DELETE)
>
>> Updating an Existing Resource
>>
>> PUT can be used to update/replace an existing resource
>>
>> *** REQUEST
>> GET /users/123 HTTP/1.1
>>
>> Host: www.example.org
>>
>> ...
>>
>> *** RESPONSE
>> 200 OK HTTP/1.1
>>
>> ...
>>
>> <html>
>>
>> ...
>>
>> <form action=”http://www.example.org/users/123” method=”put”
>> if-match=”q1w2e3r4t5”>
>>
>>  <input name=”user-name” value=”” />
>>
>>  <input name=”hat-size” value=”” />
>>
>>  <input type=”submit” />
>>
>> </form>
>>
>> ...
>>
>> </html>
>>
>> *** REQUEST
>>
>> PUT /users/123 HTTP/1.1
>>
>> Host: www.example.org
>>
>> If-Match: q1w2e3r4t5
>
> Nit: that is not a valid ETag; it needs to be in double quotes (in the HTML
> as well, so we can also use weak etags).
Yep, good catch.

>
>> ...
>
>> Other Considerations
>>
>> Below are other items for consideration.
>> Handling Responses
>>
>> Typical responses from PUT (200/201/204) and DELETE (200/202/204) SHOULD
>> be handled the same way these responses are handled for POST[cite].
>
> How *are* they handled by UAs? (Is this in HTML5?).
Excellent question<g>. I have _assumed_ since servers are free to emit
201/202/204 for POST today that the HTML WG had no real concern for
this case. It's not clear to me why adding PUT/DELETE to the list of
supported methods alters the importance of handling these types of
responses, but I'm open to hearing more about it.

>
>> ...
>
> Best regards, Julian
>

I'll work up an updated doc reflecting your feedback and post it later today.

MCA

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones
In reply to this post by Sam Ruby-2

On 01/04/2011, at 9:24 PM, Sam Ruby wrote:

>> I'm currently interested in a discussion that leads to something that
>> *could* be added to the HTML spec, and might lead to clarifications in
>> the HTTPbis specs.
>>
>> I don't think an issue tracker is the right place for that.
>
> In that case, discussions can happen anywhere; but those that could lead to changes to the W3C HTML spec should occur on public-html to ensure that all of the right people see it.
>
>> Best regards, Julian
>
> - Sam Ruby

Hi,

I will follow up on my issues and proposals here and continue on public-html if access is appropriate.

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

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones
In reply to this post by Arthur Clifford
Hi Arthur,

If you will engage in heresy, i will oblige with some evangelism :) Not because this is the place for a debate on ReST but because it is pertinent to framing the requirements of the form element in HTML5. I will try to keep my responses within this context.

On 02/04/2011, at 4:22 AM, Arthur Clifford wrote:

> I realize this may be heresy, but why is using PUT and DELETE appropriate? And why should HTML 5 or any version of HTML be considered an application development language rather than a hyper-text markup language?

I think the question can be seen from the alternative perspective of - why is using PUT and DELETE inappropriate? I will answer this below.

To answer the definition of HTML you only need to look at the charter's deliverables:

"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web."

> I would argue that the nuance of post and has historically been blurred since GET pretty much meant a CGI URL and thus had a character limit while POST was unlimited. So many of us in the field just stuck with POST even for GET operations when user input, or number of parameters went past that limit.

> Frankly, I think that the user agent requesting content via a URL should be required to do a GET, and that Forms should be required to POST, and that the method attribute be done away with to avoid confusion. REST is just remote proceedure calls. I think that PHP's superglobal $_REQUEST shows the practical perspective of things; no matter what you are doing it is just a request that you are providing parameters to. I don't think the industry standard should change to reflect an academic presumption that the HTTP POST, DELETE, GET, and PUT are "the right way" to do post parameters to a remote procedure call. There needs to be a distinction between the transfer protocol (HTTP) and the the functionality of the remote procedure calls.

I think you have a misunderstanding of what ReST is and what it is not. I would recommend you read Roy Fielding's dissertation on ReST, specifically in the context of the WWW, sections 6.5.2 - "HTTP is not RPC" and 6.5.3 - "HTTP is not a Transport Protocol".

http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2

ReST is an architectural style and an implementation of that style is the WWW - this is the architecture which marries URIs, HTTP and HTML into a single system. This *is* how the WWW works and for an example of a true ReSTful system you need look no further.

That HTML and HTTP are interlinked is because they are part of the same system. For HTML to not include full support for HTTP is to exclude one part of the system from full interaction. As HTML is the user-interface for humans to interact with resources over HTTP this limitation would be only to limit real humans from interacting with resources to the full extent that automated systems can.

This isn't about an academic presumption, this is about the architectural implementation of the WWW and for the HTTP protocol to be accessible to real humans.

> Furthermore there are nuances to GET and POST that aren't as obscure as those referenced so far in this thread. Safari, for instance, when you do GET operations even via HTTPS displays the URLS that are accessed in its Activity window in clear text. Even if you are getting content via HTTPs you need to post the parameters in order to have them encrypted. I think that is where the distinction of protocol vs remote procedure call methodology is most distinct. HTTP crud operations should NOT be used for RPC methods and they should not be confused. If REST developers, and I am one, want to distinguish between put,get, update, and delete they can create REST scripts for doing that and it would take less effort that it would to refactor the entire industry. This issue is not an HTML nor an HTTP issue is it a server-side REST API issue.
>
> That's my heretical 2-cents,
>
> Art
>
>

There is nothing stopping PUT or DELETE requests from containing body content. Your misunderstanding of ReST as RPC is due to you thinking that there is only one type of operation - to 'post' data. The HTTP specification has GET, PUT, POST, DELETE, HEAD, OPTIONS, etc because each of these are their own methods with their own semantics and unique effects\operations in the context of a resource. HTTP is like an implementation of RPC, you don't implement RPC under HTTP.

Cam

>
> On Apr 1, 2011, at 6:33 PM, mike amundsen wrote:
>
>> Subbu:
>>
>> Not sure of your question, so I'll take a shot:
>>
>> *** You might be asking if the conditional header should be present in
>> the body at all.
>> Consider cases where the response contains a list of possible
>> resources to PUT/DELETE, each possibility rendered as a FORM with the
>> response representation:
>>
>> <html>
>> ...
>> <h1>Unresolved Orders</h1>
>> <form action="..." method="delete" if-match="q1w2e3"><label>Order
>> #123</label><input type="submit" value="delete" /></form>
>> <form action="..." method="delete" if-match="w2e3r4"><label>Order
>> #456</label><input type="submit" value="delete" /></form>
>> <form action="..." method="delete" if-match="e3r4t5"><label>Order
>> #789</label><input type="submit" value="delete" /></form>
>> ...
>> </html>
>>
>> In the above example, the Etag of the response representation would be
>> insufficient as that Etag belongs to the entire response, not any of
>> the resources represented by each form in the body.
>>
>>
>> mca
>> http://amundsen.com/blog/
>> http://twitter.com@mamund
>> http://mamund.com/foaf.rdf#me
>>
>>
>> #RESTFest 2010
>> http://rest-fest.googlecode.com
>>
>>
>>
>>
>> On Fri, Apr 1, 2011 at 21:07, Subbu Allamaraju <[hidden email]> wrote:
>>> Do you need the conditional headers as form parameters? The agent should be able to replay those headers.
>>>
>>> Subbu
>>>
>>> On Apr 1, 2011, at 5:50 PM, mike amundsen wrote:
>>>
>>>> Cross-posting to related groups:
>>>>
>>>> I've posted a document[1] that shows one way in which HTML FORMS can
>>>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
>>>> quick draft but I think it covers the basics.
>>>>
>>>> If this is not in the desired format let me know.
>>>>
>>>>
>>>> [1] http://amundsen.com/examples/put-delete-forms/
>>>>
>>>> mca
>>>> http://amundsen.com/blog/
>>>> http://twitter.com@mamund
>>>> http://mamund.com/foaf.rdf#me
>>>>
>>>>
>>>> #RESTFest 2010
>>>> http://rest-fest.googlecode.com
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 1, 2011 at 16:24, Sam Ruby <[hidden email]> wrote:
>>>>> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>>>>>
>>>>>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>>>>>
>>>>>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>>>>>
>>>>>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>>>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>>>>>> *where* should this activity happen?"
>>>>>>>
>>>>>>> Where is in bug reports:
>>>>>>>
>>>>>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>>>>>
>>>>>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>>>>>> editor, you will be encouraged to join the working group and participate
>>>>>>> by creating a proposal and participating in the discussion:
>>>>>>>
>>>>>>> http://www.w3.org/html/wg/#join
>>>>>>>
>>>>>>>> best, nathan
>>>>>>>
>>>>>>> - Sam Ruby
>>>>>>
>>>>>> I'm currently interested in a discussion that leads to something that
>>>>>> *could* be added to the HTML spec, and might lead to clarifications in
>>>>>> the HTTPbis specs.
>>>>>>
>>>>>> I don't think an issue tracker is the right place for that.
>>>>>
>>>>> In that case, discussions can happen anywhere; but those that could lead to
>>>>> changes to the W3C HTML spec should occur on public-html to ensure that all
>>>>> of the right people see it.
>>>>>
>>>>>> Best regards, Julian
>>>>>
>>>>> - Sam Ruby
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones
In reply to this post by mamund

On 02/04/2011, at 11:58 AM, mike amundsen wrote:

> Julian:
>
> My comments inline....
>
> On Sat, Apr 2, 2011 at 05:50, Julian Reschke <[hidden email]> wrote:
>> On 02.04.2011 02:50, mike amundsen wrote:
>>>
>>> Cross-posting to related groups:
>>>
>>> I've posted a document[1] that shows one way in which HTML FORMS can
>>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
>>> quick draft but I think it covers the basics.
>>>
>>> If this is not in the desired format let me know.
>>>
>>>
>>> [1] http://amundsen.com/examples/put-delete-forms/
>>> ...
>>
>> Mike,
>>
>> thanks for getting this started.
>>
>> I think it's essential to think this through completely, not to rush it.
>
> I agree. we've gone w/o PUT/DELETE in HTML for more than a decade,
> working this through slowly doesn't add any hardship<g>.
>

Slow progress but progress none the less :)


>>
>> In the meantime I recalled the main reason why I got nervous about what the
>> FF4 beta implemented; it adopted the broken XHR behavior for following
>> redirects (rewriting the request method to GET), and it also had the URI
>> encoding for one of the methods wrong.
>>
>> Now looking at your proposal:
>>
>>> Summary
>>>
>>> A proposal for supporting PUT and DELETE in HTML5 Forms.
>>> Goals
>>>
>>> Support for PUT/DELETE should be:
>>>
>>>    as complete as possible (per HTTP[cite] spec)
>>>    as seamless as possible (per current Browser behaviors)
>>>    easy to use via HTML (for both servers to emit and browser to process)
>>>    not introduce any new security problems
>>>    not veer substantially from support for PUT/DELETE via XHR
>>
>> Personally I'd add "should integrate well with servers which already support
>> PUT and DELETE, such as WebDAV servers"
>
> sounds ok.
>

I would hesitate at making references to WebDAV. This is an extension of HTTP and as such introduces additional functionality which, IMO, is not appropriate for the top-level specification.


>>
>>> Assumptions
>>>
>>> This proposal assumes:
>>>
>>>    Any controls that are currently valid for FORMs with the method=”post”
>>> are also valid for FORMs with the method=”put.”
>>>    Any enc-type values that are currently valid for FORMs with the
>>> method=”post” are also valid for FORMs with the method=”put.”
>>>    All controls and enc-type values are ignored for FORMs with the
>>> method=”delete.”
>>
>> Will we need additional enc-types? Maybe something for JSON?
> PUT certainly doesn't *require* it, but if the WG wants to use PUT as
> a "stalking horse" to expand the range of enc-types supported by HTML,
> that's fine w/ me. If we go down that road, i suspect XML should also
> be added as an enc-type, too.
>


While i have no problem with JSON as an enctype, i would hesitate at adding it specifically because it leads on to supporting XML.

I honestly have no idea how form data could be represented as XML, would this be it's own schema or would authors be able to specify one?

I think the current enctypes are more than adequate at representing the form elements as they have been specifically designed for such task.


>>
>>> A Simple HTML Example
>>>
>>> <form action=”http://example.org/user/123” method=”put” if-match=”*”>
>>>
>>>  <input name=”user-name” type=”text” value=”” />
>>>
>>>  <input name=”hat-size” type=”text” value=”” />
>>>
>>>  <input type=”submit” />
>>>
>>> </form>
>>>
>>> Filling the “user-name” and “hat-size” inputs with “mike” and “small”
>>> respectively, will result in the following HTTP request:
>>>
>>> PUT /user/123 HTTP/1.1
>>>
>>> Host: example.org
>>>
>>> Content-Type: application/x-www-form-urlencoded
>>>
>>> If-Match: *
>>>
>>> ...
>>>
>>> user-name=mike&hat-size=small
>>
>> It would be good to have an example that uses non-ASCII characters.
> I'll add an example using multipart, too.
>
>>
>>> Added Attributes for the FORM element
>>>
>>> The following OPTIONAL attributes SHOULD be supported for the FORM
>>> element. Valid values for these new attributes MUST be the same as those
>>> outlined in the HTTP spec[cite].
>>> If-Match
>>> ...
>>
>> That might be hard to swallow for some (that said, I currently don't have a
>> better idea *if* we want to add this kind of control).
> Yep. this is, IMO, the key functionality missing in HTML today that
> (without it) makes PUT/DELETE unworkable for most situations. There
> are some alternatives such as
> - never sending them (will likely break w/ many existing servers,
> teaches bad habits, can result in the lost update problem)
> - always send "*" under the covers (there's a problem w/ PUT since
> PUT(create) expects "if-none-match" & PUT(update) expects "if-match")
> - adopt a non-protocol-specific model
> (method="get|post|update|create|delete" concurrency="w/aqswde")
> - there may be others
>

Yes, these attributes are definitely required. As additionals there should be no inconsistencies in introducing them.


>>
>>> Below are example usage scenarios for PUT and DELETE w/ HTML Forms.
>>>
>>>    Creating a new resource
>>>    Editing an existing resource
>>>    Deleting and existing resource
>>>
>>> Creating a new resource
>>>
>>> PUT can be used to create a new resource on the server.
>>>
>>> *** REQUEST
>>> GET /users/;create HTTP/1.1
>>>
>>> Host: www.example.org
>>>
>>> ...
>>>
>>> *** RESPONSE
>>> 200 OK HTTP/1.1
>>>
>>> ...
>>>
>>> <html>
>>>
>>> ...
>>>
>>> <form action=”http://www.example.org/users/123” method=”put”
>>> if-none-match=”*”>
>>>
>>>  <input name=”user-name” value=”” />
>>>
>>>  <input name=”hat-size” value=”” />
>>>
>>>  <input type=”submit” />
>>>
>>> </form>
>>>
>>> ...
>>>
>>> </html>
>>
>> If we wanted to make the user # a variable instead of hardwiring it into the
>> action attribute, we'd need to make it a URI template, right?
> Templates are an option (although the I-D is still in flux there,
> right?). I suspect this is primarily interesting in the PUT(create)
> case as PUT(update) and DELETE can easily get complete URIs. HTML
> adopted the pattern of encoding INPUT values into the URI for GET and
> into the body for POST. Seems awkward to "mix" these two behaviors for
> PUT/DELETE, but I'm open to exploring support for URI Templates in
> HTML.
>

I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...

why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.


>>
>>> *** REQUEST
>>>
>>> PUT /users/123 HTTP/1.1
>>>
>>> Host: www.example.org
>>>
>>> If-None-Match: *
>>>
>>> Content-Type: application/x-www-form-urlencoded
>>>
>>> Content-Length: nnn
>>>
>>> user-name=mike&hat-size=small
>>>
>>> *** RESPONSE
>>>
>>> 200 OK HTTP/1.1
>>>
>>> ...
>>>
>>> <html>
>>>
>>> ...
>>>
>>> <ul>
>>>
>>>  <li>user-name: mike</li>
>>>
>>>  <li>hat-size: small</li>
>>>
>>> </ul>
>>>
>>> ...
>>>
>>> <html>
>>
>> This makes the assumption that a sender of a PUT request always is
>> interested in a response body that describes the new state, which is most
>> certainly *not* what most current implementations of PUT do.
>>
>> Somebody mentioned that this could be handled using "Accept:", but I'm not
>> entirely sure this will work well. An alternative would be using something
>> like what James Snell describes in
>> <http://trac.tools.ietf.org/html/draft-snell-http-prefer-03#section-5>.
> Yeah, Snell's notion seems closer to what might be desireable. Of
> course, having agent add a new (optional) header will not likely
> improve the results from any existing servers.
>

I suggested using the Accept header as this is how content negotiation works everywhere... why reinvent what is already there? Why should it be ignored just because the request is from a form submission?

I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.

Current implementations of PUT and DELETE definitely won't be returning content but then these services currently aren't designed for human interaction anyway. They will require forms to be created and they will require the HTML results of processing those forms to be created too.


>>
>> (The same of course applies to DELETE)
>>
>>> Updating an Existing Resource
>>>
>>> PUT can be used to update/replace an existing resource
>>>
>>> *** REQUEST
>>> GET /users/123 HTTP/1.1
>>>
>>> Host: www.example.org
>>>
>>> ...
>>>
>>> *** RESPONSE
>>> 200 OK HTTP/1.1
>>>
>>> ...
>>>
>>> <html>
>>>
>>> ...
>>>
>>> <form action=”http://www.example.org/users/123” method=”put”
>>> if-match=”q1w2e3r4t5”>
>>>
>>>  <input name=”user-name” value=”” />
>>>
>>>  <input name=”hat-size” value=”” />
>>>
>>>  <input type=”submit” />
>>>
>>> </form>
>>>
>>> ...
>>>
>>> </html>
>>>
>>> *** REQUEST
>>>
>>> PUT /users/123 HTTP/1.1
>>>
>>> Host: www.example.org
>>>
>>> If-Match: q1w2e3r4t5
>>
>> Nit: that is not a valid ETag; it needs to be in double quotes (in the HTML
>> as well, so we can also use weak etags).
> Yep, good catch.
>
>>
>>> ...
>>
>>> Other Considerations
>>>
>>> Below are other items for consideration.
>>> Handling Responses
>>>
>>> Typical responses from PUT (200/201/204) and DELETE (200/202/204) SHOULD
>>> be handled the same way these responses are handled for POST[cite].
>>
>> How *are* they handled by UAs? (Is this in HTML5?).
> Excellent question<g>. I have _assumed_ since servers are free to emit
> 201/202/204 for POST today that the HTML WG had no real concern for
> this case. It's not clear to me why adding PUT/DELETE to the list of
> supported methods alters the importance of handling these types of
> responses, but I'm open to hearing more about it.
>

I would suggest that ALL http responses MUST be rendered by the user agent. It should make no matter what the response status is for a user to see the result of their request.


>>
>>> ...
>>
>> Best regards, Julian
>>
>
> I'll work up an updated doc reflecting your feedback and post it later today.
>
> MCA
>


Apologies for the brevity of the responses...please ask me to clarify anything which is under specified. I will continue looking at this and try to provide some more feedback.

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

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Julian Reschke
On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
> ...
>>> Personally I'd add "should integrate well with servers which already support
>>> PUT and DELETE, such as WebDAV servers"
>>
>> sounds ok.
>>
>
> I would hesitate at making references to WebDAV. This is an extension of HTTP and as such introduces additional functionality which, IMO, is not appropriate for the top-level specification.
> ...

As a normative reference, no. As a use case to be considered, yes.

> ...
>
> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>
> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.

There are use cases for PUT-to-create. Namely, when you *want* to enable
the client to name the resource.

> ...
>> Yeah, Snell's notion seems closer to what might be desireable. Of
>> course, having agent add a new (optional) header will not likely
>> improve the results from any existing servers.
>>
>
> I suggested using the Accept header as this is how content negotiation works everywhere... why reinvent what is already there? Why should it be ignored just because the request is from a form submission?

The reason why I'm nervous is that I'm not sure that Accept: ever has
used for this purpose, and it also doesn't convey the intent of a client.

Remember that "Accept: text/html" doesn't tell the server *what* the
client wants to see, just the format. So do you return a status message,
or a representation of the resource?

> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.

That is true.

What I want to avoid though is that a server can't support PUT for both
forms and other kinds of clients on the same URI.

> Current implementations of PUT and DELETE definitely won't be returning content but then these services currently aren't designed for human interaction anyway. They will require forms to be created and they will require the HTML results of processing those forms to be created too.

Sorry? They are not designed for *browser* interaction, but still
they'll interact with users.

> ...
>>> How *are* they handled by UAs? (Is this in HTML5?).
>> Excellent question<g>. I have _assumed_ since servers are free to emit
>> 201/202/204 for POST today that the HTML WG had no real concern for
>> this case. It's not clear to me why adding PUT/DELETE to the list of
>> supported methods alters the importance of handling these types of
>> responses, but I'm open to hearing more about it.
>>
>
> I would suggest that ALL http responses MUST be rendered by the user agent. It should make no matter what the response status is for a user to see the result of their request.

Is this the case today? Need test cases.

 > ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Nathan Rixham-2
Julian Reschke wrote:

> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>> I think PUT and DELETE should follow POST in regards to the action
>> URI. Personally i'm not too keen on GETs producing URIs and would
>> prefer there to be at least the option of embedding the form data.
>> Maybe this could be specified as a new encType - "text/uri" or
>> somelike...
>>
>> why would the need for a template arise? to PUT to a resource implies
>> the resource already exists, it can be used as a creational operation
>> as described in the example but that would seem to be leeking
>> server-side implementation details (the id) into the client and
>> introduce coupling.
>
> There are use cases for PUT-to-create. Namely, when you *want* to enable
> the client to name the resource.

Yes, or when you (/server) want to specify/suggest where the resource
should be PUT to within the HTML (after all, any predetermined value in
the form @action for PUT will be precisely that).

>> I think the focus on existing servers and services is unhelpful for
>> the specification of new features. Of course they won't be supported
>> retrospectively but it's about allowing new services to function fully.
>
> That is true.
>
> What I want to avoid though is that a server can't support PUT for both
> forms and other kinds of clients on the same URI.

Likewise, I strongly feel that some common use cases for PUT would be say:

1) coupling <form>, <input type="file"> and <progress> together in some
way to allow somebody to say PUT an image/jpeg (with the correct
Content-Type value)

2) PUTting some text/* or application/* specified in a <textarea> to a
location, again with the correct Content-Type set.

If those are supported then all manner of clever domain specific server
side juggling of representations can be done for those that want to try
and juggle between application/x-form-urlencoded and say application/json.

I'd suggest that it would be easy to foresee a simple apache mod that
enabled simple PUTting and DELETEing on resources, storing the
representations as received, and that any efforts to support either PUT
or DELETE should be focussed towards something people can actually use,
out of the box, without any complex code implementation or domain
specific understanding of experimental media types like
application/x-form-urlencoded or POST centric ones like multipart/form-data.

Best,

Nathan

Reply | Threaded
Open this post in threaded view
|

contenteditable and PUT - was Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Nathan Rixham-2
Nathan wrote:

> Julian Reschke wrote:
>> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>> That is true.
>>
>> What I want to avoid though is that a server can't support PUT for
>> both forms and other kinds of clients on the same URI.
>
> Likewise, I strongly feel that some common use cases for PUT would be say:
>
> 1) coupling <form>, <input type="file"> and <progress> together in some
> way to allow somebody to say PUT an image/jpeg (with the correct
> Content-Type value)
>
> 2) PUTting some text/* or application/* specified in a <textarea> to a
> location, again with the correct Content-Type set.
>
> If those are supported then all manner of clever domain specific server
> side juggling of representations can be done for those that want to try
> and juggle between application/x-form-urlencoded and say application/json.
>
> I'd suggest that it would be easy to foresee a simple apache mod that
> enabled simple PUTting and DELETEing on resources, storing the
> representations as received, and that any efforts to support either PUT
> or DELETE should be focussed towards something people can actually use,
> out of the box, without any complex code implementation or domain
> specific understanding of experimental media types like
> application/x-form-urlencoded or POST centric ones like
> multipart/form-data.

Actually to be brutally honest, I'd personally find a coupling of
contenteditable with in browser PUT/DELETE buttons far more useful (so
one could edit an HTML document in browser then PUT it back), as would
most of my clients. Especially if it were also enabled for text/ types too.

Best,

Nathan

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones
In reply to this post by Julian Reschke

On 02/04/2011, at 4:58 PM, Julian Reschke wrote:

> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>> ...
>>>> Personally I'd add "should integrate well with servers which already support
>>>> PUT and DELETE, such as WebDAV servers"
>>>
>>> sounds ok.
>>>
>>
>> I would hesitate at making references to WebDAV. This is an extension of HTTP and as such introduces additional functionality which, IMO, is not appropriate for the top-level specification.
>> ...
>
> As a normative reference, no. As a use case to be considered, yes.

Ahh, agreed. I think it provides a great example of the kind of system which would benefit from the additional functionality however it is its extension to the http protocol which is negating it from being a drop-in replacement for a client user interface.

>
>> ...
>>
>> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>>
>> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.
>
> There are use cases for PUT-to-create. Namely, when you *want* to enable the client to name the resource.

Sure, so the template would be based on some form field then?

I would probably just model that as a POST to the higher resource, in this case, http://www.example.org/users/

I can see the use case, but i thought the introduction of uri templates would probably be far greater scope...?


>
>> ...
>>> Yeah, Snell's notion seems closer to what might be desireable. Of
>>> course, having agent add a new (optional) header will not likely
>>> improve the results from any existing servers.
>>>
>>
>> I suggested using the Accept header as this is how content negotiation works everywhere... why reinvent what is already there? Why should it be ignored just because the request is from a form submission?
>
> The reason why I'm nervous is that I'm not sure that Accept: ever has used for this purpose, and it also doesn't convey the intent of a client.

I'm not sure what purpose you're referring to... the purpose of defining the format of the response?

It's not supposed to convey the intent of the client - that is for the URI, method, form data. I guess the entire request conveys the whole intent of the client, but this should include what format they want in response.

> Remember that "Accept: text/html" doesn't tell the server *what* the client wants to see, just the format. So do you return a status message, or a representation of the resource?

The content of the response should be whatever the resource deems to be the content...it could be a status message or it could be a full representation. It doesn't really matter, but the important thing is that the user gets a content response if the resource defines one.

I think that for PUT, POST, DELETE i am thinking more in terms of a URI + body = Resource in this regard... in that context, the resource is unique and possibly unreferencable but you can't bookmark a POST, PUT or DELETE.

In this regard you would be able to have a resource which technically doesn't exist - a failed request to create a resource will return back a representation at that address but only in the context of the request that was recieved. This would be returned using the appropriate HTTP response code as it does for automated agents but for some reason all User-Agent responses have been forced to return 200s, even for errors.

Let me create a sample:

*** REQUEST
GET /users/;create HTTP/1.1
Host: www.example.org
Accept: text/html
...


*** RESPONSE
200 OK HTTP/1.1
Content-Type: text/html
...
<html>
...
<form action=”http://www.example.org/users/123” method=”put”>
 <input name=”user-name” value=”” />
 <input name=”hat-size” value=”” />
 <input type=”submit” />
</form>
...
</html>


*** REQUEST
PUT /users/123 HTTP/1.1
Host: www.example.org
Accept: text/html
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn

user-name=mike&hat-size=small


*** RESPONSE
201 CREATED HTTP/1.1
Content-Type: text/html
...
<html>
...
<ul>
 <li>user-name: mike</li>
 <li>hat-size: small</li>
</ul>
...
<html>


ALTERNATIVE: Validation Error

*** RESPONSE
400 BAD REQUEST HTTP/1.1
Content-Type: text/html
...
<html>
...
<form action=”http://www.example.org/users/123” method=”put”>
 <p class="error">User name already exists</>
 <input name=”user-name” value=”mike” />
 <p class="error">Unknown hat size</>
 <input name=”hat-size” value=”small” />
 <input type=”submit” />
</form>
...
<html>


ALTERNATIVE: Accept: application/xml

*** RESPONSE
201 CREATED HTTP/1.1
Content-Type: application/xml
...
<xml>
  <user name="mike" hat-size="small"/>
<xml>


ALTERNATIVE: Accept: application/xml

*** RESPONSE
400 BAD REQUEST HTTP/1.1
Content-Type: application/xml
...
<xml>
  <errors>
        <error field="user-name" reason="NON_UNIQUE"/>
        <error field="hat-size" reason="UNKNOWN_ENUM"/>
  </errors>
<xml>


>
>> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.
>
> That is true.
>
> What I want to avoid though is that a server can't support PUT for both forms and other kinds of clients on the same URI.


Isn't this a requirement of HTTP? The same URI should be capable of accepting and producing different content based on the Accept and Content-Type headers. So, these should all be valid:

*** REQUEST
PUT /users/123 HTTP/1.1
Host: www.example.org
Content-Type: application/x-www-form-urlencoded
Accept: text/html

user-name=mike&hat-size=small


*** REQUEST
PUT /users/123 HTTP/1.1
Host: www.example.org
Content-Type: application/xml
Accept: application/xml

<xml>
  <user name="mike" hat-size="small"/>
</xml>


*** REQUEST
PUT /users/123 HTTP/1.1
Host: www.example.org
Content-Type: application/json
Accept: application/json

{user-name="mike" hat-size="small"}

>
>> Current implementations of PUT and DELETE definitely won't be returning content but then these services currently aren't designed for human interaction anyway. They will require forms to be created and they will require the HTML results of processing those forms to be created too.
>
> Sorry? They are not designed for *browser* interaction, but still they'll interact with users.

Yeah...i have the opinion that if it's not possible in a browser a human can't do it :)

Not without a custom built desktop client... <shudder>


>
>> ...
>>>> How *are* they handled by UAs? (Is this in HTML5?).
>>> Excellent question<g>. I have _assumed_ since servers are free to emit
>>> 201/202/204 for POST today that the HTML WG had no real concern for
>>> this case. It's not clear to me why adding PUT/DELETE to the list of
>>> supported methods alters the importance of handling these types of
>>> responses, but I'm open to hearing more about it.
>>>
>>
>> I would suggest that ALL http responses MUST be rendered by the user agent. It should make no matter what the response status is for a user to see the result of their request.
>
> Is this the case today? Need test cases.
>
> > ...
>
> Best regards, Julian


No this isn't the case today, but i believe it makes far more sense and is the role User-Agents are meant to be filling. It would be such a small change to make as well, pretty much the recommendation is for User-Agents to ignore the response code and just render the content.

Thanks,
Cam


Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones
In reply to this post by Nathan Rixham-2

On 02/04/2011, at 5:11 PM, Nathan wrote:

> Julian Reschke wrote:
>> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>>> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>>>
>>> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.
>> There are use cases for PUT-to-create. Namely, when you *want* to enable the client to name the resource.
>
> Yes, or when you (/server) want to specify/suggest where the resource should be PUT to within the HTML (after all, any predetermined value in the form @action for PUT will be precisely that).
>
>>> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.
>> That is true.
>> What I want to avoid though is that a server can't support PUT for both forms and other kinds of clients on the same URI.
>
> Likewise, I strongly feel that some common use cases for PUT would be say:
>
> 1) coupling <form>, <input type="file"> and <progress> together in some way to allow somebody to say PUT an image/jpeg (with the correct Content-Type value)
>
> 2) PUTting some text/* or application/* specified in a <textarea> to a location, again with the correct Content-Type set.
>
> If those are supported then all manner of clever domain specific server side juggling of representations can be done for those that want to try and juggle between application/x-form-urlencoded and say application/json.
>
> I'd suggest that it would be easy to foresee a simple apache mod that enabled simple PUTting and DELETEing on resources, storing the representations as received, and that any efforts to support either PUT or DELETE should be focussed towards something people can actually use, out of the box, without any complex code implementation or domain specific understanding of experimental media types like application/x-form-urlencoded or POST centric ones like multipart/form-data.
>
> Best,
>
> Nathan


I think operating over files is a great example of how useful these operations can be and frames the problem into a far more real-world scenario for html over the way these operations are usually discussed in terms of XML and business processing.

I'm not sure if forms can support other media type encodings. The file input can specify an 'accept' attribute but i don't even think this would be sent with the file data under normal form encodings.

Thanks,
Cam



Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Nathan Rixham-2
Cameron Heavon-Jones wrote:

> On 02/04/2011, at 5:11 PM, Nathan wrote:
>
>> Julian Reschke wrote:
>>> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>>>> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>>>>
>>>> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.
>>> There are use cases for PUT-to-create. Namely, when you *want* to enable the client to name the resource.
>> Yes, or when you (/server) want to specify/suggest where the resource should be PUT to within the HTML (after all, any predetermined value in the form @action for PUT will be precisely that).
>>
>>>> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.
>>> That is true.
>>> What I want to avoid though is that a server can't support PUT for both forms and other kinds of clients on the same URI.
>> Likewise, I strongly feel that some common use cases for PUT would be say:
>>
>> 1) coupling <form>, <input type="file"> and <progress> together in some way to allow somebody to say PUT an image/jpeg (with the correct Content-Type value)
>>
>> 2) PUTting some text/* or application/* specified in a <textarea> to a location, again with the correct Content-Type set.
>>
>> If those are supported then all manner of clever domain specific server side juggling of representations can be done for those that want to try and juggle between application/x-form-urlencoded and say application/json.
>>
>> I'd suggest that it would be easy to foresee a simple apache mod that enabled simple PUTting and DELETEing on resources, storing the representations as received, and that any efforts to support either PUT or DELETE should be focussed towards something people can actually use, out of the box, without any complex code implementation or domain specific understanding of experimental media types like application/x-form-urlencoded or POST centric ones like multipart/form-data.
>>
>> Best,
>>
>> Nathan
>
>
> I think operating over files is a great example of how useful these operations can be and frames the problem into a far more real-world scenario for html over the way these operations are usually discussed in terms of XML and business processing.
>
> I'm not sure if forms can support other media type encodings. The file input can specify an 'accept' attribute but i don't even think this would be sent with the file data under normal form encodings.

Which begs the question, is <form> even the correct approach? It appears
to me that the fucntionality of forms will have to be special cased and
effectively constrained just to do PUT (only certain elements make sense
or would have a use, arguably) or DELETE (no elements really make any
sense).

So perhaps, fresh eyes and a new approach, new elements, may be in
order. That is, if it's not deemed that the use cases are so different
and complicated that it infact makes more sense to just use scripting
and xhr!

Best,

Nathan

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: PUT and DELETE methods in 200 code]

cameronjones

On 02/04/2011, at 6:50 PM, Nathan wrote:

> Cameron Heavon-Jones wrote:
>> On 02/04/2011, at 5:11 PM, Nathan wrote:
>>> Julian Reschke wrote:
>>>> On 02.04.2011 17:32, Cameron Heavon-Jones wrote:
>>>>> I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...
>>>>>
>>>>> why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.
>>>> There are use cases for PUT-to-create. Namely, when you *want* to enable the client to name the resource.
>>> Yes, or when you (/server) want to specify/suggest where the resource should be PUT to within the HTML (after all, any predetermined value in the form @action for PUT will be precisely that).
>>>
>>>>> I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.
>>>> That is true.
>>>> What I want to avoid though is that a server can't support PUT for both forms and other kinds of clients on the same URI.
>>> Likewise, I strongly feel that some common use cases for PUT would be say:
>>>
>>> 1) coupling <form>, <input type="file"> and <progress> together in some way to allow somebody to say PUT an image/jpeg (with the correct Content-Type value)
>>>
>>> 2) PUTting some text/* or application/* specified in a <textarea> to a location, again with the correct Content-Type set.
>>>
>>> If those are supported then all manner of clever domain specific server side juggling of representations can be done for those that want to try and juggle between application/x-form-urlencoded and say application/json.
>>>
>>> I'd suggest that it would be easy to foresee a simple apache mod that enabled simple PUTting and DELETEing on resources, storing the representations as received, and that any efforts to support either PUT or DELETE should be focussed towards something people can actually use, out of the box, without any complex code implementation or domain specific understanding of experimental media types like application/x-form-urlencoded or POST centric ones like multipart/form-data.
>>>
>>> Best,
>>>
>>> Nathan
>> I think operating over files is a great example of how useful these operations can be and frames the problem into a far more real-world scenario for html over the way these operations are usually discussed in terms of XML and business processing.
>> I'm not sure if forms can support other media type encodings. The file input can specify an 'accept' attribute but i don't even think this would be sent with the file data under normal form encodings.

multipart/form-data would send the content-type.

>
> Which begs the question, is <form> even the correct approach? It appears to me that the fucntionality of forms will have to be special cased and effectively constrained just to do PUT (only certain elements make sense or would have a use, arguably) or DELETE (no elements really make any sense).
>
> So perhaps, fresh eyes and a new approach, new elements, may be in order. That is, if it's not deemed that the use cases are so different and complicated that it infact makes more sense to just use scripting and xhr!
>
> Best,
>
> Nathan

Which functionality of the form will need to be special cased for PUT or DELETE?

The only additions would seem to be the etag attributes which are non-offensive and highly desirable in my opinion.

Any content which is possible for POST must be possible for PUT.

I agree the case for customizing DELETE seems strange, why would you upload a file to delete a resource? There is nothing about the DELETE method which precludes if from containing any form of content in the body of the request, and with some further thought i can even think of where a case were this would be desirable.

What about if when DELETE-ing a resource the server requires a digital signature file to be uploaded with the request? Maybe this is a specific security mechanism on a resource-by-resource basis?

What about if there is some other conditional attributes required for a successful DELETE operation? The form element can capture these and so while security and conditions will *probably* be handled elsewhere doesn't mean they *must* be handled elsewhere.

From the perspective of the HTTP protocol, there are no special requirements and hence i don't see any reason to introduce any special handling in HTML.

Thanks,
Cam
12