【问题标题】:Read and edit the content of an HttpResponseMessage读取和编辑 HttpResponseMessage 的内容
【发布时间】:2015-06-19 05:48:47
【问题描述】:

我有一个 DelegatingHandler 的实现,它基本上接受一个请求并将其发送到另一台服务器 (http://localhost:9999/test/page.php --> http://otherSite.com/test/page.php )。

根据我的问题here,我现在必须阅读页面的结果并进行一些编辑:

protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
{
    string url = request.RequestUri.PathAndQuery;
    UriBuilder forwardUri = new UriBuilder(_otherWebSiteBase);
    forwardUri.Path = url;

    HttpRequestMessage newRequest = request.Clone(forwardUri.Uri.ToString());

    HttpResponseMessage responseMessage = await _client.SendAsync(newRequest);
    //HERE: How to read the responseMessage.Content in string?
    return responseMessage;
}

我正在尝试阅读消息的内容,更改其中的某些部分(基本上将所有 http://otherSite.com 更改为 http://localhost:9999 )然后返回。

我面临的问题:

string content =await responseMessage.Content.ReadAsStringAsync();
  1. 不返回任何可读的内容(我不确定,但我觉得可能是因为压缩?)
  2. 有没有办法替换邮件内容?

【问题讨论】:

    标签: c# .net asp.net-web-api asp.net-web-api2


    【解决方案1】:

    我试图更好地理解这一点。您是否只是希望将所有发往该地址的请求重定向到另一个地址?鉴于您将它放在委托处理程序中,我想象它正在为每个传入的请求运行。

    如果是这样,我真的不相信这是编写此代码的位置。我认为还有两个地方可以提供更清洁的解决方案。

    在网络服务器中:

    您似乎在重新创建反向代理 (https://en.wikipedia.org/wiki/Reverse_proxy) 的想法,您希望一台服务器在客户端不知道更改的情况下简单地将请求定向到另一台服务器。您可以在服务器本身上进行此修改。如果您使用的是 IIS,有一些指南可以使用 IIS 插件(如应用程序请求路由)来实现此目的(http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing)。其他网络服务器也有自己的解决方案,但我没有亲自尝试过。

    在路线本身

    在响应此请求的任何 Web API 路由上,您都可以使用 http 状态代码告诉浏览器将请求重定向到其他地方。

    3xx系列就是专门为解决此类问题而制作的:http://www.restapitutorial.com/httpstatuscodes.html


    也就是说,如果您仍想使用原始问题中的方法,您需要确保返回的数据类型存在 Media-Type Formatter。默认情况下,Web API 只会尝试对 JSON、XML 和 Form-url 编码的数据使用格式化程序。如果您要返回其他任何内容,则需要做更多的工作 (http://www.asp.net/web-api/overview/formats-and-model-binding/media-formatters) 以获取数据以进行操作。

    【讨论】:

    • 感谢您的赞赏回答! 对于您的第一点:这个概念有点像您所描述的,除了:代理将在客户端,并且我必须修改部分内容。此外,客户端将通过不同的主机名访问它。这背后的原因是:客户端应该可以选择直接访问真实的网站,并且托管 web api 的 c# 应用程序应该能够使用 web 客户端发送具有相同会话的请求。
    • 第二点:我不确定完全理解使用这些状态码会产生什么结果,但我觉得我无法编辑返回的内容,并且用户将被重定向到真实的网站,这不是预期的。 第三点:我期待完整的旧纯 html(我没有这里的代码,但我很确定它是 text/html 但内容不可读(一些无法识别的字符). 我在响应头看到gzip,是不是需要先解压?还是说明我不支持?
    • @J4N 如果压缩是关键点,那么 netomatix.com/development/httpcontentencoding.aspx 是 Accept-Encoding http 标头的一个很好的参考,msdn.microsoft.com/en-us/library/… 类将使您能够解压缩内容。您可以通过禁用 Header 中的压缩并查看返回的结果来进行快速测试,但出于性能原因,理想情况下您希望保持压缩。
    猜你喜欢
    • 2021-10-16
    • 1970-01-01
    • 1970-01-01
    • 2012-01-28
    • 1970-01-01
    • 2013-04-02
    • 1970-01-01
    相关资源
    最近更新 更多