- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Tue, 13 Dec 2011 19:22:03 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
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 UTC