W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: PUT and DELETE methods in 200 code

From: mike amundsen <mamund@yahoo.com>
Date: Tue, 5 Apr 2011 09:59:13 -0400
Message-ID: <BANLkTikqL-CpHB3TarfKw=Yppqcsg399TA@mail.gmail.com>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, public-html@w3.org
On Tue, Apr 5, 2011 at 09:55, Cameron Heavon-Jones <cmhjones@gmail.com> wrote:
>
> On 04/04/2011, at 6:57 PM, Julian Reschke wrote:
>
>> On 04.04.2011 19:49, Cameron Heavon-Jones wrote:
>>> ...
>>> Doesn't this leave the default behaviour of services to be browser-sniffing again? If no decision can be made based on Accept, there is no other information from which to deduce the content to produce, if any. That a user requires the information is only deducible by the UA.
>>
>> Well, we should do better than browser sniffing.
>>
>
> Indubitably :)
>
>
>>> The alternative is to mandate that content is provided for all responses (even if that content is empty), and for the server to pick the most relevant format by means of Accept.
>>
>> The hard part is not whether or not to send content, but *what* to send. Some clients may want a new representation of the resource (PUT->200), some will not.
>>
>>> ...
>>
>> BR, Julian
>
>
> Ok, so the Accept header can only be used to define the format of the response.
>
> But isn't it the server's responsibility to define the content for each format? Why can a server not have the following mapping?
>
> PUT /user/123
>
> Accept: text/plain -> "User created"
> Accept: application/xml -> <xml><user id="123"/></xml>
> Accept: application/json -> {id:123}
> Accept: text/html -> <html>...</html>
>
> The verboseness or brevity of the responses can be defined by the service and on a format-by-format basis.
>
> For "Accept: ", ie undefined, the service may default to the most appropriate format, probably text/plain, or maybe even a 204. There is nothing stopping services from returning different status codes for different requests.
>
> I think i'm starting to take the view that this may even be out of scope for forms, should the responsibility of forms not be to provide the interface for a user to tailor a http request? As long as the request is valid, the form has fulfilled its role and after that point it is the UA's responsibility to handle the response to that request in conformance with http.

I, too, think this particular item is out-of-scope for PUT/DELETE HTML
FORMS. I see it's value; possibly using PUT _heightens_ the appeal of
some way for agents to suggest the response "style" (status-only,
body-content, etc.).

>
> The response handling from form submissions could be included in html but more as recommended guidelines than specification. The http spec has already defined the behaviour has it not?
>
> cam
Received on Tuesday, 5 April 2011 13:59:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:27 GMT