On 02/04/2011, at 7:09 PM, Cameron Heavon-Jones wrote: > > 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
As an additional reason for a URI mime for encType, this would allow for DELETE methods to be initiated in the same manor as GETs, for example: <form encType="text/uri" method="DELETE" action="http://www.exmaple.com/users";> <input name="hat-size" type="text"/> <input name="submit"/> </form> would result in the following request: *** REQUEST DELETE /users?hat-size=small HTTP/1.1 Host: www.example.org Accept: text/html *** RESPONSE 200 OK HTTP/1.1 Content-Type: text/html ... <html> ... <ul> <p>The following users have been deleted with hat-size=small:</p> <li>user-name: mike</li> <li>user-name: bob</li> <li>user-name: jim</li> </ul> ... <html>
