Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Feb 21, 2012 11:21 PM by pierslawson
Feb 20, 2012 09:47 AM|LINK
If a user agent doesn't specify a q factor to indicate its preferred media format, it would be good for the order of the values supplied to be taken into account. Whilst the HTTP spec does not specify what should happen when the same q factor applies to
two or more formats, many user agents don't use q factor fully so using the order would help. Some examples:
Feb 21, 2012 08:03 PM|LINK
Another, perhaps more serious issue with the Accept handling is when the server can't match any of the supplied formats... the server should return a 406 Not Acceptable error. Instead it rturns the default format, JSON.
Feb 21, 2012 08:39 PM|LINK
We already have a bug tracking the issue with not returning a 406 - Not Acceptable when the media types in the accept header cannot be satisfied . This will be fixed for the next release.
Feb 21, 2012 08:50 PM|LINK
Can bugs be seen / raised externally or is that an internal list only? Would the ordering issue also be addressed as part of the same fix?
Feb 21, 2012 09:31 PM|LINK
Sending a representation other than one in the accept header is a valid choice for the server -- it is in control. I agree that there are sceanarios where a 406 would be very useful (that's why we introduced it) but it has to be configurable as both are
Hope this helps,
Feb 21, 2012 11:21 PM|LINK
Thanks for your reply Henrik
I agree the HTTP spec says the server "SHOULD" (their capitalisation) return 406, so yes, strictly the server could ignore the user agent's stated requirements. Having said that, I would suggest if you are going to make it configurable, you should make the
default be that a 406 is returned... otherwise clients will not only have to check the status code returned but also the content-type.
Have you considered my original suggestion in this thread regarding using the order of acceptable formats when the q factor is identical. I raised this as it was request put to me by a user of my REST
framework for MVC (which I hope I can retire now!!!). Its a simple change that some people were hitting in the real world.