我们遇到过这样的问题：用户最终会通过“空的 GET 请求”访问我们的网站。我的意思是，他们从外部网站发出带有多个参数的 POST 请求，但浏览器只会对我们的服务器执行简单的 GET 操作，不带任何参数。
无论使用什么浏览器，也无论使用什么技术，很多网站都或多或少地会发生这种情况。
无论出于什么原因，更新我们的证书（已经使用了 18 个月）解决了这个问题。旧证书来自 Verisign，新证书来自 Thawte。
水平线下方是原始问题。
我们有一项服务，我们期望各种网络商店通过 HTTPS 向我们发送 POST 数据，并将数据有效负载作为 nvp POST 参数。其中一小部分在某处转换为 GET 请求，有效负载丢失，因此它们以 GET 请求的形式到达我们的服务器，没有任何参数。
当我们收到 GET 请求时，我们的负载均衡器或防火墙上没有任何迹象表明 POST 请求会以任何方式与我们收到的 GET 相关联。GET 通常是我们从给定 IP 看到的第一个传入请求。
除了几乎所有客户端计算机都是各种版本的 Windows 之外，似乎没有其他共同因素。浏览器至少可以是 Firefox、IE 或 Chrome 中的任何一种。
通过用户浏览器提交数据（使用 POST 方法的表单）的其他站点可以使用以下任何一种方式（但不限于此）；
PHP、Java、Ruby on Rails、.NET
Linux、Windows
Apache、Nginx、IIS、Tomcat、Cowboy
Drupal、Magento、Joomla、Prestashop、专有和内部解决方案
该问题影响了多个不同站点的客户，这些站点似乎没有任何共同点。而且用户似乎并非来自某个特定的 ISP。
似乎发生了这样的事情：POST 请求消失了，从未到达我们的任何服务器。不知何故，浏览器发送了一个没有任何参数的 GET 请求。但是，根据我们的测试，引用者是完整的，这意味着用户不可能选择浏览器地址字段并按下 Enter，因为这会丢失引用者标头。重试一次或几次（浏览器返回，重新单击引用网站上的提交）后，POST 就会按应有的方式通过
此外，根据我们所听到的最终用户的评论，他们没有收到浏览器错误消息。
服务器到服务器的调用似乎不受此问题的影响。问题似乎始于 7 月 14 日，因为在此日期之后，我们每天都会收到这些问题请求。一开始每天只有几个，之后一直在稳步上升，现在已经稳定在我们收到的所有 API 请求的每天约 5% 左右。
因此，这看起来不像是引用站点的问题，因为它影响的是具有如此多不同平台且没有共同因素的站点。这看起来确实像是 Windows 问题，因为问题用户代理实际上是各种版本的 Windows，但它影响所有浏览器，那么可能是什么呢？
此时欢迎任何建议。
编辑：我们会查看它是否是 http -> https 重定向，因为我们对此进行了测试并在负载均衡器日志中找到了 http 请求。据我所知，我们的负载均衡器也会发生非 www 到 www 的重定向，我们也会看到这种情况。另外忘了提到，我们从受影响的站点获得的数据大多是有效的，只有一小部分请求表现不稳定。
编辑： * 已解决（有点）* 出于“这没什么用，但不管怎样我们还是试一试吧，因为我们不知道哪里出了问题”的想法，我们安装了一个新证书。安装新证书后，这个问题就不复存在了。
我们目前不知道证书是如何导致我们遇到的行为的。据我所知，如果证书有问题，浏览器会提示用户采取行动（据我们所知，没有人收到任何提示），要么根本不与服务器通信，要么正常进行。我没想到浏览器会将 POST 更改为 GET 并转储所有参数。旧证书安装正确，否则它怎么可能一年半以来一直运行良好？
无论如何，大约一周内没有出现任何案例。日志中显示这些问题案例之一的最后一条记录的时间大约是在安装新证书之前几分钟……
答案1
很难猜测，但这可能是重定向，更具体地说是 HTTP -> HTTPS 重定向。为了实现这种情况，您的服务器上需要从 HTTP 重定向到 HTTPS，并且您可能不会在日志中看到这些，因为您可能将它们放在不同的地方。
因此，场景可能是客户端由于某种原因（某种形式在某处错过了正确的方案）向 HTTP 发送 POST，获取重定向代码并使用 GET 导航到 HTTPS。
如果不是这种情况，则可能是不同的重定向（例如非 www 到 www 前缀或类似）。您应该在日志中看到这些，但您可能会因为某种原因而错过它们（以某种方式根据 HTTP 代码进行过滤？）。但这不像 HTTP->HTTPS 重定向那样可能。
那么，事实就是这样吗？或者你能证明事实并非如此吗？