Remove some dead code (ResponseFormatterSelectionResult.MatchOnResponseContentType) left over from content negotiation changes.
Fix #77 null ref on server when binding to complex parameter with null Content
http://aspnetwebstack.codeplex.com/workitem/77

Parameter should be null. Added a TaskHelpers.NullResult() helper for getting a task with result=null object. Modified other callsite to use this.
Moving around the increment on RequestsOutstanding for selfhost
fixing stress bug: Uri route parameters messed up for Controllers in stress.
This is already checked in for RC branch, now we're applying the fix in RTM. The model metadata contains state that's per request, therefore it can't be cached. Let see where the perf numbers are before we comeup with a more complex fix.
Add Receive and Send Timeout as settings on HttpSelfHostConfiguration
Make ModelBinderAttribute support IModelBinder in addition to ModelBinderProvider.
This is more reasonable now that the ModelBinderProvider contract has been simplified.
This is also more consistent with MVC scenarios.
337659: Replace Add with AddWithoutValidation for HttpContent headers
This is a simple fix where we'll use HttpContentHeaders.TryAddWithoutValidation instead of HttpContentHeaders.Add because we already know the header we're adding is valid.
Minor exception cleanup:

1) Renamed "Error.ArgumentGreaterThanOrEqualTo" to "Error.ArgumentMustBeGreaterThanOrEqualTo" for consistency and applied to OutOfRange exceptions that did not use it

2) Various parsers threw IOException when they encountered bad input but that it not the appropriate exception as it may not have anything to do with IO per se. They now throw InvalidOperationException which is our catch-all for these kinds of things.
Support for progress notification in HttpClient using a pluggable HttpMessageHandler.

This feature defines an HttpMessageHandler which inserts progress notification for both request entities being uploaded and response entities being downloaded. It keeps track of where the uploads and downloads are byte-wise, not whether the HTTP operation is in looking up DNS or establishing TCP connection as this is not exposed from HttpWebRequest.

The ProgressMessageHandler exposes two events for tracking upload and download progress respectively. Each progress notification is associated with a specific request so it is possible to track progress notifications from multiple ongoing requests at the same time.

The ProgressMessageHandler is hooked in like any other HttpMessageHandler on the client side using the HttpClient constructor overload which takes a message handler pipeline, for example:

// Create progress handler and wire up to inner handler
var progressHandler = new ProgressMessageHandler(new HttpClientHandler());

// Wire up events
progressHandler.HttpSendProgress += MySendProgressHandler;
progressHandler.HttpReceiveProgress += MyReceiveProgressHandler;

// Create HttpClient
var client = new HttpClient(progressHandler)
Fixed Work Item 48 - Tests failing in non-US cultures

Added additional DateTimeOffsetExpression Theory data
Limit the recursive depth of model binding
Issue #28. Make AuthorizeCore protected in WebAPI's authorize attribute

Make the method protected virtual and rename it to IsAuthorized.
388230 Setting FromUri.Name="" still uses parameter name as prefix
The fix will allow empty string to be used as Prefix just like in MVC.
Change private to protected virtual to make it easier for implementing your own IActionValueBinder.
Have action selector use the cached version of the action binding rather than recompute it.
Issue #47 Formatters need to clone headers before adding to SupportedMediaTypes

Fix Xml and Json media type formatters so that each instance has new instances in the SupportedMediaTypes collection.
Also fixed a copy/paste issue in an unrelated test
Fixed a bug in MIME multipart parser where we didn't correctly recover from partial boundary matches within the body part content.
Addressing issues 85 [1] and 86 [2] regarding cookies:

1) Subnames can contain any character as they are encoded using URL encoding. It is only the cookie name that has a restricted character set. I have clarified this by calling out explicitly that subnames are indeed subnames and hence are different from the cookie name.

2) Due to a bug in FormDataCollation a leading "?" was skipped when parsing URI encoded data. The reason was that it expected the query string to come from a URI which does have a leading "?". Fixed to only skip "?" if coming directly from a URI query component.

Also, the cookie test classes were not marked as public and hence not run by test normally.

Henrik

[1] http://aspnetwebstack.codeplex.com/workitem/85
[2] http://aspnetwebstack.codeplex.com/workitem/86
Based on code feedback adds convenience overload for finding a particular cookie header among a set of cookie headers. The missing overload fills a gap where it was hard to find a cookie header value containing a particular CookieState name. The overload returns all cookie header values that have a CookieState with a matching name. Match is determined by case-insensitive string comparison.
Addressing user feedback on MIME multipart support programming model (see http://aspnetwebstack.codeplex.com/workitem/53).

Support for reading MIME multipart messages as handled by the HttpContent.ReadAsMultipartAsync extension methods had two usability problems in the original design:

1) The result was IEnumerable<HttpContent> which is too low-level to facilitate easy consumption. For example, it doesn't allow for converting multipart html form data into NameValueCollection data or for any other higher-level abstraction on top of the raw IEnumerable<HttpContent>

2) The stream provider doesn't enable any post processing of the data such as converting the read data into another format before the read task completed. This makes it impossible to provide a higher-level abstraction on top of IEnumerable<HttpContent> as the StreamProvider does not know when the message has been completely read.

This check-in fixes these short comings by first changing the signature of the ReadAsMultipartAsync from

    public static Task<IEnumerable<HttpContent>> ReadAsMultipartAsync(this HttpContent content, IMultipartStreamProvider streamProvider)

to

    public static Task<T> ReadAsMultipartAsync<T>(this HttpContent content, T streamProvider) where T : MultipartStreamProvider

It is now possible to write a MultipartStreamProvider that is completely tailored to the type of MIME multipart that it can read and present the result in the optimal way to the user.

Second, we introduce a “post processing” step as part of the MultipartStreamProvider that allows the implementation to do whatever post processing it wants on the MIME multipart body parts. For example, the MultipartFormDataStreamProvider implementation reads the FORM data parts and adds them to a NameValueCollection so they are easy to get at from the caller.

As part of this check-in we remove the helper functions for manipulate IEnumerable<HttpContent>. The functionality is now directly supported by the various MultipartStreamProvider implementations including MultipartFormDataStreamProvider, MultipartFileStreamProvider, and MultipartRelatedStreamProvider.