最大名称表字符计数配额
本文关键字:字符 | 更新日期: 2023-09-27 18:35:05
我有一个WCF服务(基于SOAP),它在调用某些Web方法时开始遇到以下异常:
System.Xml.Xml异常:读取 XML 数据时已超出最大名称表字符计数配额 (16384)。名称表是一种数据结构,用于存储 XML 处理过程中遇到的字符串 - 具有非重复元素名称、属性名称和属性值的长 XML 文档可能会触发此配额。可以通过更改创建 XML 读取器时使用的 XmlDictionaryReaderQuotas 对象上的 MaxNameTableCharCount 属性来增加此配额。第 1 行,位置 4221。 at System.Xml.XmlExceptionHelper.ThrowXmlException
虽然我们已经通过增加服务和客户端配置中的配额来解决此问题,但在我们开始解决问题之前和应用配额增加之后,我看不到消息响应没有差异。
我的问题是:
-
名称表如何真正工作?拥有具有最大值的名称表意味着什么?
-
有什么东西可以解释为什么我们在不更改服务和测试用例的情况下开始遇到此异常?不过,我们添加了几个方法,但我不确定这是否是一个很好的解释,因为这些 Web 方法没有被调用。
-
关于调试名称表的任何建议,看看是什么原因导致溢出?
谢谢
-
解析 XML 时,消息中的每个元素/属性名称都放在某个表中,因此可以有效地重用它们。 此配额的原因是为了避免 DOS(拒绝服务攻击),例如,有人发送非常大的消息来消耗您的所有服务器处理代码。 如果您不希望发生这种情况,则可以使用 MAX。
-
也许您更改了 WCF 版本,因此默认值已更改。 此外,某些原因可能导致客户端以不同的方式进行序列化(例如,更多属性),因此它发送了更详细的内容。
-
只是增加配额并忘记它..你不想调试这个
不过,我们添加了几个方法,但我不确定这是否是一个很好的解释,因为这些 Web 方法没有被调用。
在 WCF 应用程序中发生更改后,我看到了类似的行为,我们只是向协议中的一个 XML 消息添加了一些属性。事实证明,这些新属性有点长(每个~25个加字符),通过减少它们的长度,问题消失了。
鉴于问题出现在我们的打开会话消息中,该消息很小,并且错误堆栈显示了自动生成的 XML 序列化程序,我得出结论,作为优化步骤,自动生成的 XML 序列化程序尝试在首次使用时预填充 XML 解析器的命名表,而不更改其默认最大大小 16Kb 以匹配根据"编译"XML 架构的实际大小。这就解释了为什么当 WCF 堆栈尝试反序列化一个小 XML 请求时会发出请求。
添加此行解决了上述问题:
webHttpBinding.ReaderQuotas.MaxNameTableCharCount = 32768;