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
