问题描述
尝试使用akka-http对某些内部端点进行简单的POST请求时遇到问题.执行这段代码后:
I have an issue when trying to do a simple POST request to some internal endpoint using akka-http. When this piece of code is executed:
for {
request <- Marshal(merchantTransactionRequest).to[RequestEntity]
response <- Http().singleRequest(
HttpRequest(
method = HttpMethods.POST,
uri = "http://foo/bar:8080",
entity = request.withContentType(ContentTypes.`application/json`)
)
)
...
} yield ...
我遇到以下错误:
,紧随其后的是以下日志:
which is immediately preceded by the following log:
作为调试过程的一部分,我使用curl对该端点执行了相同的查询,该查询取得了神奇的成功(并以HTTP/1.1
响应).由于HttpRequest(...)
默认使用protocol = HttpProtocols.`HTTP/1.1`
,因此我怀疑akka-http与该另一个端点之间协商的HTTP版本不正确.
As part of my debugging journey, I executed the same query to the endpoint using curl, which magically succeeded (and responds with HTTP/1.1
). Since HttpRequest(...)
defaults to using protocol = HttpProtocols.`HTTP/1.1`
, it is my suspicion that somehow the HTTP version negotiated between akka-http and this other endpoint is incorrect.
当akka-http执行POST时,是否可以以某种方式强制实施HTTP版本?或其他任何有关为何curl成功执行POST而akka-http无法成功的线索?请注意,问题仅在执行POST时发生,而不在GET时发生.
Is it possible to somehow enforce a HTTP version when akka-http does a POST? Or any other clue as to why curl succeeds doing the POST, while akka-http does not? Note that problem only occurs while doing POST's, not GET's.
推荐答案
事实证明,该问题有一个非常奇怪的解决方案:与其通过地址 http://foo/bar:8080 (使用我们的内部DNS解析器),我们使用 https://我们的domain.com:443 .在那种情况下,一切都按预期进行.似乎akka-http因缺少TLD而受到困扰.
It turned out the problem had a very strange solution: Instead of connecting to directly connecting to the other endpoint through address http://foo/bar:8080 (using our internal DNS resolver), we connected indirectly to the endpoint using https://our-domain.com:443. Everything worked as expected in that case. It seems that akka-http is somehow troubled by the absence of a TLD.
这篇关于Akka-http POST结果为“不支持服务器端HTTP版本".的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!