Currently, the extension "CreateResponse<T>()" on the Request object creates a con-negable response. This extension currently sends back a 406 status code, when it does NOT find any formatter to write.
We have seen scenarios where uses wanted to receive a 406 status code when we match on the Type only. Yesterday's check-in related to "con-neg cleanup" provides a flag to indicate if we should match on Type or not, which probably fixes that issue.
But I think we need to handle more 406 scenarios. Examples are match based on Request Content-Type only, non-matching Accept-Charset etc.
I propose that we have a flag in the ContentNegoitationResult to say if we found the user-desired match...
The flow which I recommend is:
1. ContentNegotiator is asked for a best matching response formatter.
2. If Negotiator finds one, but it also gives information(probably a flag) of whether its confirms to the request's accept headers.
3. Caller(here the CreateResponse extension) of this Negotiator can check this flag to decide whether to send back a 406 response or not.
if we have a flag on the ContentNegotiationResult, the matches like MatchOnCanWriteType, MatchOnRequestContentType etc will be able to tell that this match is a NON-desirable user match.
Comments: The kind of behavior belongs in the ContentNegotiator. The ContentNegotiator exists so that it is possible to override the default behavior -- either by providing a custom negotiator that derives from the default one or by creating an entirely new negotiator.
We have seen scenarios where uses wanted to receive a 406 status code when we match on the Type only. Yesterday's check-in related to "con-neg cleanup" provides a flag to indicate if we should match on Type or not, which probably fixes that issue.
But I think we need to handle more 406 scenarios. Examples are match based on Request Content-Type only, non-matching Accept-Charset etc.
I propose that we have a flag in the ContentNegoitationResult to say if we found the user-desired match...
The flow which I recommend is:
1. ContentNegotiator is asked for a best matching response formatter.
2. If Negotiator finds one, but it also gives information(probably a flag) of whether its confirms to the request's accept headers.
3. Caller(here the CreateResponse extension) of this Negotiator can check this flag to decide whether to send back a 406 response or not.
if we have a flag on the ContentNegotiationResult, the matches like MatchOnCanWriteType, MatchOnRequestContentType etc will be able to tell that this match is a NON-desirable user match.
Comments: The kind of behavior belongs in the ContentNegotiator. The ContentNegotiator exists so that it is possible to override the default behavior -- either by providing a custom negotiator that derives from the default one or by creating an entirely new negotiator.