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
