【问题标题】:Rewrite http request based on response location header - Istio根据响应位置标头重写 http 请求 - Istio
【发布时间】:2019-03-02 00:02:43
【问题描述】:

说明:

通过 virtual_service 向上游请求 Istio (1.0.6) 代理。服务响应标头 newuri,带有 httpStatus 代码,即 307 - 我知道重定向应该由设计者使用 302 和位置标头进行。但我想根据 http 错误进行重定向处理。 我尝试将 envoyFilters 与 lua 一起使用,但所有功能都与流处理(请求/响应标头模块)有关,而不是重写或请求转发。

所以请求路径是这样的:

  • 客户端正在发出请求,即 curl http://foo/path
  • 代理正在将请求转发到上游
  • 上游响应带有 new_uri 的自定义标头,即 http://blabla/path2 作为值
  • 当响应代理中存在标头时,正在向 new_uri 发出新请求
  • 客户端查看来自 new_uri 的响应

谢谢

【问题讨论】:

    标签: proxy kubernetes istio envoyproxy


    【解决方案1】:

    如果您有预定义的上游主机列表,您可以考虑查看 Envoy Retry plugin。此机制允许您确定可以与某些特定重试条件 retry_on 相关联的 Hosts predicates 列表:即特定 HTTP 错误代码;和重试系列的数量num_retries,因此在重试次数达到重试次数后,Envoy 重试策略将从retry_host_predicate 中定义的列表中选择下一个主机。

    {
      "retry_on": "...",
      "num_retries": "{...}",
      "per_try_timeout": "{...}",
      "retry_priority": "{...}",
      "retry_host_predicate": [],
      "host_selection_retry_max_attempts": "...",
      "retriable_status_codes": []
    }
    

    在其他情况下,当您的重定向主机事先不知道时,最好找到一种在应用程序级别应用适当逻辑的方法,因为大多数 HTTP 代理的设计方式都是同步执行响应处理程序,即当响应处理程序正在运行时,不会在同一个线程中安排其他任何事情。这很好,只要响应处理程序只处理内存中已经存在的数据并且不等待远程服务。但是,如果您从响应处理程序发出网络请求,则整个线程将被阻塞,并且在远程服务回复之前完全不执行任何操作,这将导致性能下降。

    【讨论】:

    • 您好,感谢重播,但我看到我们有一些误解,我只是想知道如何在 istio-proxy (envoy) 级别执行重定向。因此,如果服务是对我的响应 307,istio 会自动跟随“Location”标头并从“Location”向我发送响应
    猜你喜欢
    • 1970-01-01
    • 2014-12-18
    • 1970-01-01
    • 2021-07-08
    • 2013-10-27
    • 2023-03-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多