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
