Currently some of TAP-based methods in the aspnetwebstack libraries does not have overloads with _CancellationToken_ parameter. For instance following classes:
_System.Net.Http_: HttpContent and successors.
```
HttpContent: ReadAsStringAsync, ReadAsByteArrayAsync, ReadAsStreamAsync, etc.
```
_System.Net.Http.Formatting_: HttpContent extensions.
```
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
HttpContentMultipartExtensions: ReadAsMultipartAsync
HttpContentFormDataExtensions: ReadAsFormDataAsync
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
MultipartStreamProvider: ExecutePostProcessingAsync
```
_System.Net.Http.Formatting_: MediaTypeFormatter and successors.
```
MediaTypeFormatter: ReadFromStreamAsync, WriteToStreamAsync
BufferedMediaTypeFormatter
FormUrlEncodedMediaTypeFormatter
JsonMediaTypeFormatter
XmlMediaTypeFormatter
```
_System.Web.Http_: Model binder which breaks cancellable pipeline.
```
FormatterParameterBinding: ReadContentAsync
```
Methods of above classes potentially may be executed for a long time period. In addition if we're trying to create custom _MediaTypeFormatter_ we unable to cancel _ReadFromStreamAsync_ and _WriteToStreamAsync_ methods.
I suppose that it will be great if such methods will contain an overloads with a _CancellationToken_ parameter, which should be properly integrated into Web API message processing pipeline.
Code sample how it can be refactored: https://aspnetwebstack.codeplex.com/SourceControl/network/forks/dtretyakov/CancellationToken/contribution/4472
P.S. Discussions looks dead - no answers for over 2 weeks: http://aspnetwebstack.codeplex.com/discussions/438601
Comments: I agree, it is needed to add such feature. In our case, we're using ReadAsMultipartAsync() for stream-based upload of large files and had to throw OperationCancelledException() in our Stream wrapper, that contains cancellation checking logic and checks property called CancelPending of the associated I/O descriptor class in overridden Read/Write methods. if a client wants to cancel upload request (via AJAX), then I/O descriptor's property CancelPending is set to true and whenever parser's Task calls Read/Write method on the Stream, this property is being checked before calling underlying stream's methods. The exception, that is thrown in Read/Write methods causes Task returned by ReadAsMultipartAsync() to stop further processing that is being indicated by Task.IsFaulted in the MVC controller and check Task's Error property. Nevertheless, this is not so clean, but the only way for us how to indirectly stop the upload processing task whose "Cancel" is initiated from the server's side upon receiving client's cancel request. The advantage in our case is, that we can insert our cancellation logic layer via Stream wrapper class into the MIME multipart upload parser, which gets stream by calling GetStream() method from the passed MultipartStreamProvider. However, in other cases where injecting own cancellation logic is impossible, the cancellation token support in the cases you mentioned is really welcome.
_System.Net.Http_: HttpContent and successors.
```
HttpContent: ReadAsStringAsync, ReadAsByteArrayAsync, ReadAsStreamAsync, etc.
```
_System.Net.Http.Formatting_: HttpContent extensions.
```
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
HttpContentMultipartExtensions: ReadAsMultipartAsync
HttpContentFormDataExtensions: ReadAsFormDataAsync
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
MultipartStreamProvider: ExecutePostProcessingAsync
```
_System.Net.Http.Formatting_: MediaTypeFormatter and successors.
```
MediaTypeFormatter: ReadFromStreamAsync, WriteToStreamAsync
BufferedMediaTypeFormatter
FormUrlEncodedMediaTypeFormatter
JsonMediaTypeFormatter
XmlMediaTypeFormatter
```
_System.Web.Http_: Model binder which breaks cancellable pipeline.
```
FormatterParameterBinding: ReadContentAsync
```
Methods of above classes potentially may be executed for a long time period. In addition if we're trying to create custom _MediaTypeFormatter_ we unable to cancel _ReadFromStreamAsync_ and _WriteToStreamAsync_ methods.
I suppose that it will be great if such methods will contain an overloads with a _CancellationToken_ parameter, which should be properly integrated into Web API message processing pipeline.
Code sample how it can be refactored: https://aspnetwebstack.codeplex.com/SourceControl/network/forks/dtretyakov/CancellationToken/contribution/4472
P.S. Discussions looks dead - no answers for over 2 weeks: http://aspnetwebstack.codeplex.com/discussions/438601
Comments: I agree, it is needed to add such feature. In our case, we're using ReadAsMultipartAsync() for stream-based upload of large files and had to throw OperationCancelledException() in our Stream wrapper, that contains cancellation checking logic and checks property called CancelPending of the associated I/O descriptor class in overridden Read/Write methods. if a client wants to cancel upload request (via AJAX), then I/O descriptor's property CancelPending is set to true and whenever parser's Task calls Read/Write method on the Stream, this property is being checked before calling underlying stream's methods. The exception, that is thrown in Read/Write methods causes Task returned by ReadAsMultipartAsync() to stop further processing that is being indicated by Task.IsFaulted in the MVC controller and check Task's Error property. Nevertheless, this is not so clean, but the only way for us how to indirectly stop the upload processing task whose "Cancel" is initiated from the server's side upon receiving client's cancel request. The advantage in our case is, that we can insert our cancellation logic layer via Stream wrapper class into the MIME multipart upload parser, which gets stream by calling GetStream() method from the passed MultipartStreamProvider. However, in other cases where injecting own cancellation logic is impossible, the cancellation token support in the cases you mentioned is really welcome.