Jersey客户端：Jenkins重定向时身份验证失败

我正在尝试使用Jenkins的RESTAPI。Jenkins需要向URL发送POST请求才能删除作业。其结果如下：

我告诉我选择的客户将帖子发送到适当的URL。
客户端发送帖子，并使用用户名和密码对自己进行授权

詹金斯删除了这份工作

Jenkins返回一个“302-Found”，其中包含包含已删除作业的文件夹的位置

客户端自动向该位置发送帖子

詹金斯的回答是“200-OK”和文件夹页面的完整HTML

这对邮递员来说很好（当然，除非我禁用了“自动跟踪重定向”）。 然而，Jersey在第5步一直遇到“404”，因为我阻止匿名用户查看相关文件夹。（如果我完全屏蔽了匿名用户，则为“403”） 请注意，身份验证在步骤1中起作用，因为作业已成功删除

我的印象是Jersey应该对所有有关客户端的请求使用给定的身份验证。 有没有办法真正做到这一点？我真的不想为了自己做每一个重定向而禁止重定向

澄清一下：问题是while Jersey遵循重定向，但无法再次验证自身，导致服务器拒绝第二个请求

有关守则：

HttpAuthenticationFeature auth = HttpAuthenticationFeature.basicBuilder()
    .credentials(username, token)
    .build();
Client client = ClientBuilder.newBuilder()
    .register(auth)
    .build();
WebTarget deleteTarget = client.target("http://[Jenkins-IP]/job/RestTestingArea/job/testJob/doDelete")  
Response response = deleteTarget.request()
    .post(null);

编辑：根据邮差，“302已找到”只有5个标题：日期、X-Content-Type-Options（“nosniff”）、位置、内容长度（0）和服务器。所以，邮递员不会使用任何饼干或代币，泽西也不会忽视

问题与之松散相关-如果我能够记录第二个请求，我可能能够理解幕后发生的事情

---

EDIT2:我还确定问题显然在于身份验证。如果我允许匿名用户查看有问题的文件夹，错误将消失，服务器将以200回答。

我在和的帮助下找到了答案

TL；DR:这是预期行为，您必须设置系统属性

http.strictPostRedirect=true

使其工作或自己执行第二个请求

---

如前所述，

HttpURLConnection

决定不实现HTTP标准中定义的重定向，而是实现了许多浏览器（用外行的话说，“像其他人一样做，而不是像它应该如何工作”）。这会导致以下行为：

将帖子发送到URL_1

服务器回答为“302-Found”，并包含URL_2

发送GET到URL_2，删除所有标题

服务器以“404-未找到”应答，因为第二个请求未包含正确的身份验证头

“404”响应是代码接收到的响应，因为步骤2和3被底层代码“隐藏”

---

通过删除所有头，身份验证将失败。由于Jersey在默认情况下使用该类，这会导致我所经历的行为。

那么在第一次身份验证之后会发生什么，是否有令牌或cookie被发送回？你还没有真正解释过认证部分是如何成功地与邮递员合作的。嗨，保罗，我不确定我是否理解你对第二部分的意思，因为我对REST的总体经验不是很丰富。授权类型是“Basic Auth”，如果这是您的意思，那么它只是一个用户名和密码。（嗯，“密码”是在服务器上生成的令牌，但它仍然需要基本的授权方式…）我在我的帖子的回复中添加了详细信息-基本上，回复只包含“日期、X-Content-Type-Options、位置、内容长度、服务器”。不幸的是，没有cookie或令牌。Jersey看起来不像是在处理重定向。相反，较低级别的连接器处理它。例如，如果您使用默认的HttpUrlConnection连接器，它有一个方法来设置您是否要遵循重定向，并且它从您设置的Jersey属性中获取该方法。根据我提供的信息，从逻辑上讲，我看不出如果不按照您的建议手动操作，您如何能够实现这一点。其他连接器具有设置重定向的相同选项。因此，要么编写自己的连接器，要么自己手动处理重定向。您如何验证第二个请求（重定向后）也是POST？看起来大多数互联网都是通过将第二个请求转换为GET来工作的，并且删除了头。在这种情况下，您很可能会面临您所面临的问题。您是否也尝试了

http.strictPostRedirect=true

系统属性以查看它是否有效？