从使用HTTP 500错误代码失败的.Net Web服务捕获数据

I have a .net web-service hosted in IIS 6.0 that periodically fails with an http 500 because a client connects to it with data that does not match the wsdl.

我有一个在IIS 6.0中托管的.net Web服务,它定期因http 500而失败,因为客户端使用与wsdl不匹配的数据连接到它。

Things like having an element specified in a method as being of type int and the inbound xml element contains a decimal number.

比如将方法中指定的元素设置为int类型和入站xml元素包含十进制数。

WSDL element definition:

WSDL元素定义:

<s:element minOccurs="1" 
    maxOccurs="1" 
    form="unqualified" name="ItemCount" type="s:int" >

provided element:

<ItemCount>1.0</ItemCount>

This leaves a 500 error in the iis logs but no information of the soap fault returned or the input data that caused the error.

这会在iis日志中留下500错误,但不会返回soap错误信息或导致错误的输入数据。

Currently I have diagnosed several problems with data provided by capturing everything using wireshark but I'd like to know of other options that a perhaps less intrusive.

目前我已经通过使用wireshark捕获所有数据来诊断出数据存在的几个问题,但我想知道其他选项可能不那么具有侵入性。

Is there any way of capturing the data being sent that is causing the 500 errors (hopefully ONLY capturing the data when the 500 occurs)? Possibly by:

是否有任何方法可以捕获导致500错误的正在发送的数据(希望仅在500发生时捕获数据)?可能是:

Configuring IIS
Configuring the web-service

配置Web服务

Changing the code of the web-service

更改Web服务的代码

EDIT after testing answer provided by tbreffni

在测试tbreffni提供的答案后编辑

The answer that best fitted what I was after tbreffni's - there were several other good responses but the answer allows capture of the payload causing deserialization errors without running something like fiddler or wireshark.

答案最符合我在tbreffni之后的情况 - 还有其他几个好的响应,但答案允许捕获有效负载导致反序列化错误而不运行像fiddler或wireshark这样的东西。

Info on actually getting a SOAP extension to run is a little light so I've included below the steps I found necessary:

实际上要运行SOAP扩展的信息有点轻,所以我在下面列出了我认为必要的步骤:

Build the SOAP extension as a .dll as per the MSDN article

根据MSDN文章将SOAP扩展构建为.dll

Add the .dll to the bin directory for the service to trace

将.dll添加到bin目录以供跟踪的服务

In the web.config of the service to trace add the following to the webServices section, replacing the SOAPTraceExtension.TraceExtension and SOAPTraceExtension to match your extension.

在要跟踪的服务的web.config中,将以下内容添加到webServices部分,替换SOAPTraceExtension.TraceExtension和SOAPTraceExtension以匹配您的扩展。

<webServices>
  <soapExtensionTypes>
    <add type="SOAPTraceExtension.TraceExtension, SOAPTraceExtension" priority="1" group="0"/>
  </soapExtensionTypes>
</webServices>

6 个解决方案

#1

You could implement a global exception handler in your web service that logs the details of any exceptions that occur. This is useful for your current problem, plus it's very useful in a production environment as it gives you an insight into how many exceptions are being thrown and by what code.

您可以在Web服务中实现一个全局异常处理程序,记录发生的任何异常的详细信息。这对您当前的问题非常有用,而且它在生产环境中非常有用,因为它可以让您深入了解抛出的异常数量以及代码。

To implement an exception handler for a .Net web service, you need to create a SOAP extension. See the following MSDN Article for an example. I've used this approach in several production web services, and it's been invaluable in determining what issues are occurring and where.

要为.Net Web服务实现异常处理程序,您需要创建SOAP扩展。有关示例,请参阅以下MSDN文章。我已经在几个生产Web服务中使用了这种方法,它在确定正在发生的问题和位置方面非常有价值。

#2

I'd try fiddler or here. Not specifically for web services and typically for client side, it can be used as a reverse proxy.

我会尝试小提琴或者在这里。不是专门针对Web服务,通常是客户端,它可以用作反向代理。

It's very script-able and "request/response" aware so I think it likely you could get it to only capture 500 errors.

它非常适合脚本,并且“请求/响应”可以识别,因此我认为您可能只能捕获500个错误。

#3

I never used this myself, but I just found this in MSDN: Enabling Tracing in ASP.NET Web Services

我自己从未使用过这个,但我在MSDN中找到了这个:在ASP.NET Web服务中启用跟踪

#4

Have you looked at IIS Request-Based Tracing?: http://technet.microsoft.com/en-us/library/cc786920.aspx

你看过基于IIS请求的跟踪吗?:http://technet.microsoft.com/en-us/library/cc786920.aspx

#5

After some thinking of my own, the current best solution I can see is to throw together a light weight facade web-service that accepts an xml blob as input.

在考虑了我自己之后,我能看到的当前最佳解决方案是将轻量级外观Web服务放在一起,接受xml blob作为输入。

I can then get my facade service to call the real service with the input data provided by the client and then:

然后,我可以使用客户端提供的输入数据调用真实服务,然后:

handle any errors, logging the source data and the returned soap fault

处理任何错误,记录源数据和返回的soap错误

Pass back to the client the responses from good data

将好数据的响应传回客户端

This would only be a temporary measure (I'm strongly opposed to web-services that are not explicit about the XML they accept) but it would perhaps give me more leverage to get over the hump of diagnosing errors like this in production where the client connecting to the web-service is not honouring the wsdl or able to read soap faults returned.

这只是一个临时措施(我强烈反对那些不明确他们接受的XML的网络服务),但它可能会让我有更多的杠杆来克服在客户端的生产中诊断错误的问题。连接到Web服务不尊重wsdl或能够读取返回的soap故障。

Thankfully in this case there is only one party posting to the web-service - the packet sniffer methods (fiddler or wireshark) are feasible but the lack of logging for 500 errors did get me thinking "what nicer options are there?".

值得庆幸的是,在这种情况下,只有一方发布到Web服务 - 数据包嗅探器方法(fiddler或wireshark)是可行的,但缺少500错误的记录确实让我想到“有什么更好的选项?”。

#6

If you want a use a tool, use WireShark.

如果您想使用工具,请使用WireShark。

Otherwise, the easiest way is to capture "everything" (assuming you are using ASMX) is to enable trace on system.net

否则,最简单的方法是捕获“所有内容”(假设您使用的是ASMX)是在system.net上启用跟踪

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

If you are using WCF, it has great tracing support and you can use svctraceviewer to view the trace logs. Doesn't sound like you are using WCF though.

如果您使用的是WCF,则它具有很好的跟踪支持,您可以使用svctraceviewer查看跟踪日志。听起来不像你正在使用WCF。

#1

#2