BizTalk 2016 WCF-WebHttp 缓存 Headers
BizTalk 2016 WCF-WebHttp Caching Headers
我创建了一个仅包含自定义管道组件的发送管道,它创建了一个 mime 消息 POST 到需要 multipart/form-data 的 Rest API。它有效,但每第二次调用都会失败。它在成功和失败之间交替。当它失败时,我写入 header 的边界似乎被 WCF-WebHttp 适配器使用先前成功消息的边界覆盖。
- 我确定我正在向 header 写入正确的边界。
- 我在管道组件中使用的任何流都已添加到管道资源管理器中。
- 如果我在第一个成功消息后重新启动主机实例,下一个消息也会成功。
- 在处理每条消息之间等待 10 分钟,观察到的行为没有变化。
- 如果我在预计会发生故障时发送不同的文件,header content-length 仍然与之前的文件相同。这表明使用的 header 与之前的调用完全相同。
- 标准 BizTalk mime 组件不会将边界写入 header,因此不提供任何线索。
成功
POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate
--9ccdeb0a-c407-490c-9cce-c5e3be639785
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri
6442
--9ccdeb0a-c407-490c-9cce-c5e3be639785
失败:header 中的边界与有效载荷
中的边界不同
POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate
--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri
6442
--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Disposition: form-data; name=Files; filename=testdoc.docx; filename*=utf-8''testdoc.docx
如果我能让 header 使用正确的边界,我的问题就会得到解决。有什么建议吗?
更令我惊讶的是,您实际上使用这种方法取得了一些成功。问题是,headers 不是正式的消息属性,而是端口属性。端口缓存它们的设置。您必须使其成为动态发送端口才能正常工作。另一种方法是在自定义行为中设置 headers,但我认为这不适合您的情况。
我创建了一个仅包含自定义管道组件的发送管道,它创建了一个 mime 消息 POST 到需要 multipart/form-data 的 Rest API。它有效,但每第二次调用都会失败。它在成功和失败之间交替。当它失败时,我写入 header 的边界似乎被 WCF-WebHttp 适配器使用先前成功消息的边界覆盖。
- 我确定我正在向 header 写入正确的边界。
- 我在管道组件中使用的任何流都已添加到管道资源管理器中。
- 如果我在第一个成功消息后重新启动主机实例,下一个消息也会成功。
- 在处理每条消息之间等待 10 分钟,观察到的行为没有变化。
- 如果我在预计会发生故障时发送不同的文件,header content-length 仍然与之前的文件相同。这表明使用的 header 与之前的调用完全相同。
- 标准 BizTalk mime 组件不会将边界写入 header,因此不提供任何线索。
成功
POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate
--9ccdeb0a-c407-490c-9cce-c5e3be639785
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri
6442
--9ccdeb0a-c407-490c-9cce-c5e3be639785
失败:header 中的边界与有效载荷
中的边界不同POST http://somehost/Record HTTP/1.1
Content-Type: multipart/form-data; boundary="9ccdeb0a-c407-490c-9cce-c5e3be639785"
Host: somehost
Content-Length: 11989
Expect: 100-continue
Accept-Encoding: gzip, deflate
--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Type: text/plain; charset=utf-8
Content-Disposition: form-data; name=uri
6442
--3fe3e969-8a41-451c-aae7-8458aee0c9f4
Content-Disposition: form-data; name=Files; filename=testdoc.docx; filename*=utf-8''testdoc.docx
如果我能让 header 使用正确的边界,我的问题就会得到解决。有什么建议吗?
更令我惊讶的是,您实际上使用这种方法取得了一些成功。问题是,headers 不是正式的消息属性,而是端口属性。端口缓存它们的设置。您必须使其成为动态发送端口才能正常工作。另一种方法是在自定义行为中设置 headers,但我认为这不适合您的情况。