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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 13 Dec 2011 19:32:16 +0100
Message-ID: <4EE79A30.7060209@gmx.de>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 2011-12-13 19:17, Cameron Heavon-Jones wrote:
> ...
>> "If no Accept header field is present, then it is assumed that the client accepts all media types." (RFC 2616, Section 14.1)
> Yes, we looked at this before. Nowhere does it say what the chosen media type should be. This is an implementation choice though, and i would be more included to return a user-viewable representation like html by default.

Yes. It means the client didn't say, not that it doesn't want anything.

>>> 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?

> 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.

>>> 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.

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

> 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.

> 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
Received on Tuesday, 13 December 2011 18:32:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC