捕获异常时的原始HTTP POST数据 [英] Capturing raw HTTP POST Data during Exception

问题描述

我有一个WCF服务在接受HTTP POST IIS / ASP.NET托管（的没有形成交的）序列化对象。

如果客户端发送畸形请求（例如，他们不能正确序列化对象），我想记录发送了消息。

我们已经在使用ELMAH来捕捉未处理的异常，所以索性post数据连接将是最容易的选择。

我可以破例期间获取当前的HttpContext，但是这并不只包含HTTP头信息。

我的问题是：是否有捕获原始HTTP POST请求主体的某种方式？或者，做不到这一点 - 获取导致该错误输入的一种更好的方式（不反向代理）？

编辑：只是为了澄清，在任何时候都运行数据包级捕获是不是真的适合。我说我可以部署到生产服务器，并且将有我们的控制或监视能力，外部客户的解决方案后，很。

编辑＃2：有人建议访问Request.InputStream - 如果你想WCF已经读出的数据流的请求后读这不起作用。

code的试片，看我怎么尝试使用此就在这里。

 的StringBuilder登录=新的StringBuilder（）;        VAR请求= HttpContext.Current.Request;        如果（request.InputStream！= NULL）
        {
            log.AppendLine（的String.Format（request.InputStream.Position = \\{0} \\，request.InputStream.Position））;
            如果（request.InputStream.Position！= 0）
            {
                request.InputStream.Seek（0，System.IO.SeekOrigin.Begin）;
            }            使用（StreamReader的SR =新的StreamReader（request.InputStream））
            {
                log.AppendLine（的String.Format（原始输入：\\{0} \\，sr.ReadToEnd（）））;
            }
        }
        其他
        {
            log.AppendLine（request.Inputstream =空）;
        }
        log.ToString（）;
 

log.ToString（）的输出继电器是：

    request.InputStream.Position =0
    原来的输入：

解决方案

通过处理请求，而不是提供给你它会为你服务的时间。

不过...你可以附上的消息检查。消息督察允许您与消息拨弄它达到你的操作实现了。您可以创建消息的缓冲副本，并将其复制到OperationContext.Current。

当然丑陋的黑客攻击，而这将意味着内存开销消息现在的两个副本浮动大约为每一个请求。

I have a WCF Service hosted in IIS/ASP.NET that accepts HTTP Post (not form post) of serialized objects.

If the client sends malformed requests (eg they're not serializing the object correctly) I'd like to log the message sent up.

We're already using ELMAH to capture unhandled exceptions, so simply attaching the post data would be the easiest option.

I can get the current HttpContext during an exception, however this does only contains the HTTP Header information.

My question is this: Is there some way of capturing the original HTTP POST request body? Or, failing that - a better way (without a reverse proxy) of capturing the input that caused the error?

Edit: Just to clarify, running packet-level capturing at all times isn't really suitable. I'm after a solution that I can deploy to Production servers, and which will have clients outside our control or ability to monitor.

Edit #2: A suggestion was made to access the Request.InputStream - this doesn't work if you're trying to read after WCF has read the request off the stream.

A sample piece of code to see how I've tried using this is here.

        StringBuilder log = new StringBuilder();

        var request = HttpContext.Current.Request;

        if (request.InputStream != null)
        {
            log.AppendLine(string.Format("request.InputStream.Position = \"{0}\"", request.InputStream.Position));
            if (request.InputStream.Position != 0)
            {
                request.InputStream.Seek(0, System.IO.SeekOrigin.Begin);
            }

            using (StreamReader sr = new StreamReader(request.InputStream))
            {
                log.AppendLine(string.Format("Original Input: \"{0}\"", sr.ReadToEnd()));
            }
        }
        else
        {
            log.AppendLine("request.Inputstream = null");
        }


        log.ToString();

The ouput of log.ToString() is:

    request.InputStream.Position = "0"
    Original Input: ""

解决方案

By the time it gets to your service the request is processed and not available to you.

However ... you could attach a message inspector. Message Inspectors allow you to fiddle with the message before it reaches your operation implementations. You could create a buffered copy of the message, and copy it into the OperationContext.Current.

Ugly hack of course, and it will mean memory overhead as now two copies of the message are floating about for every request.

这篇关于捕获异常时的原始HTTP POST数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！