用于多部分 http 响应的自定义 ActionResult?
我想用 txt 文件和 html 页面响应 http 请求。 这样,客户端可以保存文件并通过 html 页面查看该文件内容的摘要。
由于该文件是动态生成的,因此我必须在服务器上使用状态管理来生成第二个请求的摘要。 我想避免这种情况并将其包含在一个响应中。
自定义的 ActionResult 会是什么样子?
I'd like to respond to an http request with both a txt file and an html page. This way the client can save the file and see a summary of that file's contents via an html page.
Since the file is generated on the fly, I have to use state management on the server to generate the summary on the second request. I'd like to avoid this and wrap this up in a single response.
What would the custom ActionResult look like?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
也在此处讨论过。
我是这样回答的:
我不不相信任何现代浏览器都支持多部分/混合。
This was also discussed here on SO.
i answered it like this:
I don't believe any modern browser supports multipart/mixed.
您可以发送引用 XSLT 样式表的 XML。 浏览器可以进行转换并显示结果 HTML 输出。
用户可以简单地执行“文件->另存为...”来存储XML文件。
You could send XML with reference to an XSLT stylesheet. The browser can do the transformation and display a resulting HTML output.
And the user may simple do "File->Save as ..." to store the XML file.
为什么不将摘要呈现为普通 HTML 视图,并在该摘要下提供一个链接,该链接指向返回二进制数据的单独 ActionResult...
Why not render the summary as normal HTML View and provide a link under that summary that points to a separate ActionResult that returns binary data...
我对这个主题进行了一些搜索,令我惊讶的是,似乎人们已经这样做了。 我在此处找到了描述,但它没有提供公共测试 URI,所以我无法测试浏览器对此的行为。 它还提到了将存档文件发送给客户端的解决方案。 但我想这不是你要找的,对吧?
这里是另一篇文章,展示了多部分响应的示例。 遗憾的是,演示 URI 似乎不再起作用。
所以情况是这样的:可以进行HTTP多部分响应。 有一些客户端库可以处理应用程序代码中的那些内容。 浏览器行为需要测试(这里有一个声音)。 使用此功能似乎是实验性的,并且可能建议仅您可以控制通信的两端,以消除互操作性问题。
I did some search on this topic and to my surprise, this seems people did this already. I found a description here, but it does not provide a public test URI, so I couldn't test browser behaviour on this. It also mentiones the solution to send an archive file to the client. But I assume that's not what you're looking for, right?
Here is another article showing an example with multipart responses. Sadly, the demo URI seems not to be working any more.
So the situation is this: HTTP multipart responses can be done. There are client (few) libraries to handle those in application code. Browser behaviour is to be tested (Here's a voice). Using this feature seems experimental and may be recommended only you can control both ends of the communication to eliminate interoperability issues.