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

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

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Tue, 13 Dec 2011 19:22:03 +0000
Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
Message-Id: <DFC70ECC-C682-4A9A-B6DB-D55E700756C1@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>

On 13/12/2011, at 6:32 PM, Julian Reschke wrote:

> On 2011-12-13 19:17, Cameron Heavon-Jones wrote:
>> ...
>>>> Accept: text\plain =>   short status message
>>> 
>>> What if the XHR client wants to embed the status message as HTML fragment into the current page?
>>> 
>> 
>> It's plain text, they can do whatever they like with a message like "Your resource has been DELETE'd".
> 
> What if the message is supposed to contain HTML?

I'm not sure what the script can't do here? It can insert anything into the current document.

> 
>> For XHR i would be more included to return "application/json" maybe with a message, status code, app-specific info. The information can be used for whatever purpose the script requires.
> 
> Yes, that's one thing that can be done, but not the only one.
> 

True.


>>>> Accept: text\html =>   representation of the collection
>>> 
>>> Again, you are overloading "Accept" with something it's not suitable for.
>>> 
>> 
>> Not so, it is perfectly acceptable and correct to return html for an "Accept: text/html". I argue that it is you who wish to do something unsuitable by returning plain text status messages in response to "Accept: text/html".
> 
> I didn't say that, you claimed I did.
> 

Yes, sorry, i thought this is what you said some WebDAV client currently do\expect?


> "Accept: text/html" means the client wants HTML. It does not indicate whether the client wants a status message or a folder UI.

Yes, my approach, and i will accept it as an approach, is that these represent different resources and require unique URIs.

> 
>> The decision being made is not *what* is being returned but how that information is rendered as a media type.  I just choose to have only 1 definition of *what*, including rendering characteristics.
>> 
>>>> I understand this may not be possible for existing implementations of servers and clients. My stance is that if you are to perform client based content-negotiation you might as well just vary on User-Agent header, it amounts to the same thing and is a bad practice, IMO :)
>>> 
>>> No, varying on UA is MUCH worse. In particular, it doesn't work as the UA is the same for XHR and form access.
>>> 
>> 
>> Yes but it amounts to a UA abstraction. You are negotiating content based on which client, not its capabilities.
> 
> Nope. It's negotiation on the client's expectation. The same client can have different expectations depending on what's going on.
> 

Yes, the client is defining the state of the representation through means other than resource identification - URI.

>> It does work with XHR and form access if the Accept header is varied.
> 
> It may work in *some* cases by abusing the Accept header.
> 
> > ...
> 
> Best regards, Julian


I really don't think i can be accused of abusing the Accept header, if anything i hold upmost conformance. I just don't vary resource state.

Thanks,
Cam
Received on Tuesday, 13 December 2011 19:22:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 19:22:35 GMT