当启用缓存时，JMeter不会跟随重定向
我在JMeter上遇到了一个奇怪的问题，几乎像是一个bug。我正在运行版本5.1.1 r1855137。
我有一个标准的HTTP请求采样器和一个HTTP缓存管理器。HTTP请求设置为follow redirects。它还设置为use keepalive，并以最多6次并行下载下载所有嵌入式资源。缓存管理器被设置为每次迭代都清除缓存，并使用cache-control/expires headers。缓存中设置了5000个元素的限制。
我创建了一个线程组，其中有一个循环控制器。HTTP请求采样器位于这个线程组和循环中。初始html" target="_blank">请求中的页面返回HTTP/1.1 302 found。我还注意到，在标题中有cache-control：private,s-maxage=0。第一次通过循环，JMeter遵循重定向并下载所有资源。随后的断言很好。第二次通过时，JMeter只发送对初始页面的请求，然后不执行重定向。下面的断言失败是因为丢失了我希望在子请求中找到的对象。
我知道这是一个缓存问题，因为如果我删除线程组中的循环控制器，而是让线程组循环，如果我保留在缓存管理器上选中的“每次迭代都清除缓存”选项，问题就会消失。如果关闭此选项，线程组循环时也会出现同样的问题。
有人知道为什么当缓存管理器处于活动状态时JMeter不遵循302重定向吗？网站提供private,s-maxage=0的缓存控制头是否没有遵循正确的协议？
共有1个答案
查看JMeter源代码，JMeter缓存2xx和304S。并得到请求。见:https://github.com/apache/jmeter/blob/master/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/control/cachemanager.java#l355
所以它不应该缓存你的302s。您是否尝试过使用自动重定向选项以查看其是否工作正常：
-
问题内容： 我不明白为什么Java 不遵循从HTTP到HTTPS URL的HTTP重定向。我使用以下代码在https://httpstat.us/上获取页面： 该程序的输出为： 对http://httpstat.us/301的请求返回以下（缩短的）响应（这似乎绝对正确！）： 不幸的是，Java HttpURLConnection不遵循重定向！ 问题答案： 仅当重定向使用相同的协议时，才遵循重定向。
-
响应标头： Cache-Control：private,max-age=3600 内容-长度：0 位置:/blog1/test 服务器:Microsoft-IIS/10.0 现状：301 用户代理:Mozilla/5.0（Windows NT 10.0；Win64；x64)AppleWebKit/537.36（KHTML,like Gecko）Chrome/61.0.3163.100 Safari
-
问题内容： 我正在测试一些针对强大压力的JSON API。然而，在某一时刻，响应时间趋于平稳的“趋势”。它增加到一个很高的点，然后下降到一个永不改变的响应时间。 我尝试取消所有两个JMeter缓存管理器选项，并将最大缓存大小设置为1。还添加了一个HTTP标头，该标头在Cache-Control上的最大寿命为零。 如何完全禁用JMeter中的缓存？ 注意 ： 我搜索了相关文章：但是，出现的是将JMe
-
我正在使用Jmeter对我的ASP.NET应用程序进行负载测试。 我正在测试搜索功能，什么是在获得结果的响应时间。 我面临的问题是，当我第一次搜索时，说我搜索了“我很好”，并说它花了9876毫秒，下次我搜索同样的东西只需要4567毫秒，第三次只需要4234毫秒。 我正在使用HTTP缓存管理器，我已经检查了“每次迭代都清除缓存”。我还使用了Http Cookie管理器，并检查了“每次迭代清除Cook
-
问题内容： 是否可以发送xhr HTTP HEAD请求以仅获取第一个请求的标头响应，而不像重定向一样自动跟随301、302？我只对获取URL的新位置感兴趣。例： http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send- method 似乎指定应遵循请求，有没有办法阻止这种情况？ 问题答案： 没有，这不是您可以停止的公开行为。
-
问题内容： 我目前正在用Go语言编写一些与REST API交互的软件。我正在尝试查询的REST API端点返回HTTP 302重定向以及HTTP Location标头，指向资源URI。 我正在尝试使用Go脚本抓取HTTP Location标头，以供以后处理。 这是我目前为实现此功能正在做的事情： 对我来说，这有点像是个骇客。通过覆盖的功能，我实际上被迫将HTTP重定向视为错误（不是）。 我已经看到