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:
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.
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.
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
valid.
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.
pierslawson
Member
48 Points
35 Posts
Accept type ordering
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:
pierslawson
Member
48 Points
35 Posts
Re: Accept type ordering
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.
vinelap
Member
28 Points
9 Posts
Microsoft
Re: Accept type ordering
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.
pierslawson
Member
48 Points
35 Posts
Re: Accept type ordering
Feb 21, 2012 08:50 PM|LINK
Thanks Vinelap,
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?
Henrik Fryst...
Member
96 Points
13 Posts
Microsoft
Re: Accept type ordering
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 valid.
Hope this helps,
Henrik
pierslawson
Member
48 Points
35 Posts
Re: Accept type ordering
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.
Piers