首先,我的问题是基于我在网上找到的一些答案,我希望有人可以做出澄清的答案.
从我目前的发现中总结出来的问题非常简短:使用CoreService,似乎WCF是默认情况下上传大于16,384字节的文件的限制.我希望我只是忽略一些非常基本的东西,这将允许我上传不仅仅是空的gif文件,而不必更改服务器配置,因为我打算将此代码用于多个SDL tridion实例.
只是为了提供上下文和我发现的内容,你可能不需要阅读所有这些内容,但由于我花了很多时间查看和尝试各种各样的事情,我想我也可以把它写下来给下一个遇到的人这个.
我正在使用CoreService Stream Upload上传文件,基于此示例: 如何使用核心服务将外部文件导入SDL Tridion 2011?
我不想复制所有代码,但我可以成功地将一个小的(empty.gif)上传到临时位置,使用它作为我的基础,然后我得到一个Windows临时文件路径.
String tempFileLocationOnServer = streamUploadPort.uploadBinaryByteArray(
fileName, data);
Run Code Online (Sandbox Code Playgroud)
对于略大的文件,80K的PDF,我得到一个例外:
反序列化操作"UploadBinaryByteArray"的请求消息体时出错.读取XML数据时已超出最大数组长度配额(16384).通过更改创建XML阅读器时使用的XmlDictionaryReaderQuotas对象上的MaxArrayLength属性,可以增加此配额.第1行,第2461位.
我发现这个WCF readerQuotas设置 - 缺点?,这似乎解释了它是WCF的问题,并且是为了防止DDOS,并且可以调整这些值.
我认为80K字节不是很多,我没有做任何我不能通过具有相同凭据的Web界面做的事情.
由于CoreService已经需要用户名/密码,我不明白为什么会出现DDOS问题,因为在有效负载之前,请求应该在身份验证上被拒绝.
我知道替代方案,如webdav或在Tridion实例上映射网络驱动器,或使用单独的网络服务器来转储文件,所以我可以在创建多媒体组件时将它们称为"外部",但我宁愿不必去那条路线.
小智 5
阅读你的问题的标题(从java),你必须注意到java解析器没有100%实现MTOM,这是Core Services用于流上传/下载的.
确保您的解析器支持MTOM或使用类似的东西创建新的绑定和端点,检查messageEnconding ="Text"属性.
<binding name="streamUpload_basicHttp" maxReceivedMessageSize="209715200"
transferMode="StreamedRequest" messageEncoding="Text"
receiveTimeout="00:10:00">
<security mode="None" />
</binding>
Run Code Online (Sandbox Code Playgroud)
它将传递base 64中的所有信息(不是性能最佳但可互操作)
归档时间: |
|
查看次数: |
825 次 |
最近记录: |