根据文档，apache http客户端应该自动重定向。我正在向服务器提交一个帖子，它有一个重定向。不幸的是，响应处理程序返回一个空字符串。它只是不遵循重定向并直接向我提供该内容。是否有一种简单的方法让客户端遵循重定向？
答案 0 :(得分：1)
你可能会看到RFC-2616特别难看的区域的结果。 Location标头用于根据确切的状态代码重定向客户端。有趣的是201,301,302和303. 正确的处理在很大程度上取决于您接收的是哪一个。我的猜测是你应该收到一个303 See Other并且你收到的是另一个代码和你的客户端正在遵循各种HTTP规范。
我不知道Apache的HTTP客户端的行为，但我知道很多服务器和客户端的实现都会导致这种行为错误。以下是RFC-2616的相关组块。我为这是一个相当冗长的答案而道歉。
<强> 10.2.2。 201创建
请求已完成，并导致创建新资源。新创建的资源可以由响应实体中返回的URI引用，其中由Location头字段给出的资源的最具体URI。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果无法立即执行操作，服务器应该响应202（已接受）响应。
<强> 10.3.2。 301永久移动
已为所请求的资源分配了一个新的永久URI，并且此资源的任何将来的引用应该使用返回的URI之一。具有链接编辑功能的客户端应尽可能自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则该响应是可缓存的。
新的永久URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。
如果收到301状态代码以响应GET或HEAD以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变条件请求已发出。
注意：在收到301状态代码后自动重定向POST请求时，某些现有的HTTP / 1.0用户代理会错误地将其更改为GET请求。
<强> 10.3.3。找到302
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires头字段指示，则此响应仅可缓存。
临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。
如果收到302状态代码以响应GET或HEAD以外的请求，则除非用户可以确认，否则用户代理不得自动重定向请求，因为这可能会改变请求的条件。发出的。
注意：RFC 1945和RFC 2068指定不允许客户端更改重定向请求的方法。但是，大多数现有的用户代理实现将302视为303响应，对Location字段值执行GET，而不管原始请求方法如何。已经为希望明确清楚客户期望哪种反应的服务器添加了状态代码303和307.
10.3.4 303见其他
可以在不同的URI下找到对请求的响应，并且应该使用该资源上的GET方法检索。此方法主要用于允许输出POST激活的脚本以将用户代理重定向到选定的资源。新URI不是最初请求的资源的替代引用。 303响应绝不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。
不同的URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。
注意：许多pre-HTTP / 1.1用户代理不了解303状态。当需要考虑与此类客户端的互操作性时，可以使用302状态代码，因为大多数用户代理会对302响应做出反应，如此处针对303所述。
答案 1 :(得分：0)
我已经尝试过使用apache HttpComponents 4.3.5，您必须指定重定向策略以遵循重定向。
我是这样做的。
HttpClient httpClient = HttpClients.custom()
.setRedirectStrategy(new LaxRedirectStrategy())
.build();