This project is read-only.

MediaTypeProcessor multiple SupportedMediaTypes and parameters

Topics: Web Api
Dec 16, 2010 at 2:37 PM

2 things I've noticed with behaviours that depend on SupportedMediaTypes:

1. The MediaTypeProcessor's ExecuteRequest() and ExecuteResponse() methods match using SupportedMediaTypes.Contains(). e.g.


if (request.Headers.ContentType != null && this.SupportedMediaTypes.Contains(request.Headers.ContentType))
  result = new ProcessorResult<object> { Output = this.ReadFromStream(request.Content.ReadAsStream(), request) };


However, it's not uncommon to find Content-Type values with additional parameters:


POST /quotes HTTP/1.1
Host: ...
Content-Type: application/atom+xml; charset=UTF-8


If in my media type processor I've specified SupportedMediaTypes as e.g.

return new[] {"application/atom+xml"}

- this isn't going to match. To get around this, I can always do this:

return new[] {"application/atom+xml", "application/atom+xml; charset=UTF-8"}

But as a developer, I don't want to have to anticipate all the likely combination of parameters and whitespacing.

2. I've got a media type processor with the following SupportedMediaTypes:

return new[] {"application/restbucks+xml", "application/xml", "text/xml"};

Even if the client specifies Accept: application/restbucks+xml, the response Content-Type is always "text/xml"


Dec 16, 2010 at 8:33 PM

Hi Ian

1. In the current bits, the match is an exact match. In the next drop however this functionality has changed. Here is how it works. When the client comes in, assuming the media types matches a processor, then if they specify a charset we will currently interpret that as "I want a processor that EXPLICITLY supports this charset" so we ensure when we match up that the processor actually does support that charset. If the charset is not supplied in the accept header, then we will just match as long as the media type matches. This is orthagonal to the qualifiers in the header which we use at a prior stage to determine the order of client preference. Now we could change this rule to say that as long as the media types match, it is a match. That would however put the burden on the implementer of the processor to support all the charsets. Which behavior would you expect?

2. That will also work in the next drop.





Dec 21, 2010 at 11:26 PM

Hi Glenn

I think the behavior as you've described it for the next drop is fine. All I'd suggest is that the matching is case, whitespace and parameter ordering insensitive to the extent defined by 2616: "The type, subtype, and parameter attribute names are case- insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value."