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.
Explicit support for stream-based push-content.

The HttpContent model supports writing data by either pushing data to the output stream directly or pulling data from an input stream and then copying it to the output stream (see blog at [1]). However, whereas pull is supported out of the box in the form of StreamContent there is no equivalent support for pushing data. This check-in adds a PushStreamContent that enables scenarios where a data producer wants to write directly (either sync or async) to an HttpContent.

When the PushStreamContent is ready to accept data it calls out to an action with the output stream. The developer can then write to the stream for as long as necessary and then close the stream when writing has completed. The PushStreamContent detects the closing of the stream and completes the underlying Task for writing out the content. PushStreamContent is entirely async and does not block any threads. It is up to the user of the PushStreamContent to write data either synchronously or asynchronously.

The second (and arguably larger) part of this check-in is that we have introduced a new Service in the Services Directory for controlling the buffering policy applied to a request and/or response by the host. The interface is called IHostBufferPolicySelector and replaces an internal static method in the Web host which could not be extended.

Henrik

[1] http://blogs.msdn.com/b/henrikn/archive/2012/02/17/push-and-pull-streams-using-httpclient.aspx
Fix FormDataCollectionExtensions.ReadAs to return the default value for value types
Merge branch 'master' into webapi