Currently Web Api on Owin implementation uses IHostBufferPolicySelector interface defined in System.Web.Http, but I feel we should have a new interface going forward on Owin.
When IHostBufferPolicySelector was designed, we had to worry
about WebHost(where HttpContextBase was passed in) and SelfHost(which did not have this) and so we were accepting 'object', but since this is Owin, we should probably avoid it and go by HttpRequestMessage as its easier to code against.
IHostBufferPolicySelector.cs:
```
namespace System.Web.Http.Hosting
{
/// <summary>
/// Interface for controlling the use of buffering requests and responses in the host. If a host
/// provides support for buffering requests and/or responses then it can use this interface to
/// determine the policy for when buffering is to be used.
/// </summary>
public interface IHostBufferPolicySelector
{
/// <summary>
/// Determines whether the host should buffer the entity body when processing a request with content.
/// </summary>
/// <param name="hostContext">The host-specific context.</param>
/// <returns><c>true</c> if buffering should be used; otherwise a streamed request should be used.</returns>
bool UseBufferedInputStream(object hostContext);
/// <summary>
/// Determines whether the host should buffer the <see cref="HttpResponseMessage"/> entity body.
/// </summary>
/// <param name="response">The <see cref="HttpResponseMessage"/>response for which to determine
/// whether host output buffering should be used for the response entity body.</param>
/// <returns><c>true</c> if buffering should be used; otherwise a streamed response should be used.</returns>
bool UseBufferedOutputStream(HttpResponseMessage response);
}
}
```
Comments: I strongly recommend this bug gets closed. It's very easy for users to create a message handler that buffers the input based on the request message if that's what they want. And it's not a common scenario either. There's no need to create a new interface.
When IHostBufferPolicySelector was designed, we had to worry
about WebHost(where HttpContextBase was passed in) and SelfHost(which did not have this) and so we were accepting 'object', but since this is Owin, we should probably avoid it and go by HttpRequestMessage as its easier to code against.
IHostBufferPolicySelector.cs:
```
namespace System.Web.Http.Hosting
{
/// <summary>
/// Interface for controlling the use of buffering requests and responses in the host. If a host
/// provides support for buffering requests and/or responses then it can use this interface to
/// determine the policy for when buffering is to be used.
/// </summary>
public interface IHostBufferPolicySelector
{
/// <summary>
/// Determines whether the host should buffer the entity body when processing a request with content.
/// </summary>
/// <param name="hostContext">The host-specific context.</param>
/// <returns><c>true</c> if buffering should be used; otherwise a streamed request should be used.</returns>
bool UseBufferedInputStream(object hostContext);
/// <summary>
/// Determines whether the host should buffer the <see cref="HttpResponseMessage"/> entity body.
/// </summary>
/// <param name="response">The <see cref="HttpResponseMessage"/>response for which to determine
/// whether host output buffering should be used for the response entity body.</param>
/// <returns><c>true</c> if buffering should be used; otherwise a streamed response should be used.</returns>
bool UseBufferedOutputStream(HttpResponseMessage response);
}
}
```
Comments: I strongly recommend this bug gets closed. It's very easy for users to create a message handler that buffers the input based on the request message if that's what they want. And it's not a common scenario either. There's no need to create a new interface.