4

首先，我的问题是基于我在网上找到的一些答案，我希望有人可以做出澄清的答案。

从我目前的发现中总结出来的问题非常简短：使用 CoreService，似乎 WCF 是默认上传大于 16,384 字节的文件的限制。我希望我只是忽略了一些非常基本的东西，这将允许我上传的不仅仅是空的 gif 文件，而无需更改服务器配置，因为我打算将此代码用于多个 SDL tridion 实例。

只是为了提供上下文和我发现的内容，您可能不需要阅读所有这些内容，但是由于我花了很多时间寻找和尝试各种事情，我想我不妨把它写下来以供下一个遇到的人使用这。

我正在使用 CoreService Stream Upload 上传文件，基于此示例： 如何使用核心服务将外部文件导入 SDL Tridion 2011？

我不想复制所有这些代码，但我可以成功地将一个小的（empty.gif）上传到一个临时位置，以此为基础，我得到一个 Windows 临时文件路径。

String tempFileLocationOnServer = streamUploadPort.uploadBinaryByteArray(
                                                                 fileName, data);

对于稍大的文件，一个 80K 的 PDF，我得到一个例外：

反序列化操作“UploadBinaryByteArray”的请求消息正文时出错。读取 XML 数据时已超出最大数组长度配额 (16384)。可以通过更改创建 XML 阅读器时使用的 XmlDictionaryReaderQuotas 对象的 MaxArrayLength 属性来增加此配额。第 1 行，位置 2461。

我发现了这个WCF readerQuotas settings - 缺点？，这似乎解释了它是 WCF 的一个问题，并且是为了防止 DDOS，并且可以调整这些值。

我认为 80K 字节并不多，我没有做任何我无法通过具有相同凭据的 Web 界面做的事情。

而且由于 CoreService 已经需要用户名/密码，我不明白为什么会出现 DDOS 问题，因为在有效负载之前，该请求应该在身份验证中被拒绝。

我知道诸如 webdav 或在 Tridion 实例上映射网络驱动器之类的替代方法，或者使用单独的网络服务器来转储文件，因此我可以在创建多媒体组件时将它们引用为“外部”，但我宁愿不必走那条路.

4

2 回答 2

5

在那里阅读您的问题的标题（来自 java），您必须注意到 java 解析器没有 100% 实现 MTOM，这就是核心服务用于流上传/下载的内容。

确保您的解析器支持 MTOM 或使用类似的方法创建新的绑定和端点，检查 messageEnconding="Text" 属性。

<binding name="streamUpload_basicHttp" maxReceivedMessageSize="209715200"
         transferMode="StreamedRequest" messageEncoding="Text" 
         receiveTimeout="00:10:00">
  <security mode="None" />
</binding>

它将传递 base 64 中的所有信息（不是性能最佳，但可互操作）

于 2012-07-02T18:52:30.800 回答
2

您可以轻松更改 WCF 阅读器配额的大小。

如果您以编程方式创建 CoreService 绑定（如此处所示），您可以在代码中更改它。

如果您使用 App.Config 文件来配置端点（例如 Tridion 在 %Tridion%/bin/client/Tridion.ContentManager.CoreService.Client.dll.config 下附带的那个），则编辑此文件并更改其配额。

我自己倾向于使用相当大的配额，并且到目前为止还没有遇到任何问题 - 正如您所说，对核心服务的访问通常受到很好的保护。

于 2012-06-29T21:07:50.210 回答