Hi, all
I'm trying to develop an extension for the Exchange Backend/mapi/emsmdb virtual directory on Exchange 2013 SP1 mailbox servers. For my application I need access to the HttpRequest input stream, something we've done without issues for OWA, EWS and RpcProxy.
However, the handler "Microsoft.Exchange.MapiHttpHandler" uses the System.Net.HttpRequest.GetBufferlessInputStream() method introduced in .Net 4.5, and that disables input stream extensibility for the HttpRequest. If an extension based on System.Web.IHttpModule invokes the HttpRequest.InputStream at or before PreRequestHandlerExecute, it succeeds but the MapiHttpHandler fails the request due to an Method Not Supported exception. If the extension tries to invoke InputStream at or after PostRequestHandlerExecute, it throws an Method Not Supported exception. The input stream is simply not available to the extension.
This problem was fixed for WCF services in .Net 4.5.1, see http://blogs.msdn.com/b/praburaj/archive/2012/09/13/accessing-httpcontext-current-request-inputstream-property-in-aspnetcompatibility-mode-throws-exception-this-method-or-property-is-not-supported-after-httprequest-getbufferlessinputstream-has-been-invoked.aspx. I believe it was done by having the handler catch the Method Not Supported exception and falling back to a classic input stream, if an extension has previously set the input mode by invoking the InputStream.
Is there any possibility of fixing the MapiHttpHandler to allow extensibility in this way? Such a fix would not affect Exchange Server users that do not run third-party extensions that make use of the fix. And clearly the fix is a known quantity, having been used in another area.
Failing that, I'd be very interested in any ideas for alternative approaches to capturing and analyzing the Mapi over Http request and response streams.
Thanks,
John Lowery