事实证明class-request->parse_response(), 在为各种更高级别的请求函数处理重定向的地方（这是它为每个后续跃点执行递归请求的地方），有一个奇怪的钩子最终会运行WP_Http->browser_redirect_compatibility() 在重定向请求上。

browser_redirect_compatibility() 非常简单：

public static function browser_redirect_compatibility( $location, $headers, $data, &$options, $original ) {
        // Browser compat
        if ( $original->status_code === 302 ) {
            $options[\'type\'] = Requests::GET;
        }
    }

基本上，只要有302重定向，它就会删除您选择的方法，并将其替换为GET. 他们似乎认为他们正在转换POST 请求，但从阅读中可以清楚地看到，这将适用于除GET 结果是302。

但值得注意的是DOESN\'T 对301重定向有任何影响，并且似乎与302的错误相关。您可以在[上一个问题中]阅读更多关于302及其问题的信息，该问题与POST 请求转换为获取和丢失数据](Temporary redirect prevents getting $_POST array)

影响Apache但不影响Nginx

这似乎很相关：我的本地开发环境使用MAMP，站点通过Apache托管，这就引发了一个疯狂的问题。

我们的live站点使用Nginx->Varnish->Nginx设置，无论出于何种原因，都不会使用相同的重定向302 但实际上301 因此工作正常（他们保持PURGE 在重定向的位置https URL的版本，而不是http 版本）。

因此，我建议所有有此问题的人：

• 完全切换到Nginx，因为它似乎不使用302进行此类重定向。Apache suxhttps 开始是一个明显的改进，将使我们的日志更干净）