我经历了“seven layers of the candy cane forest” 关于这一点…：）
我们的插件通过POST请求接收数据。在安装了插件的特定站点上，我们观察到了奇怪的行为。In one specific scenario, the POST requests were erroneously generating a 404 (Not Found) error.
我从一开始就非常宽泛，一点一点地缩小问题范围，直到我剩下以下复制场景。令人费解的错误发生在：
将任何“POST”请求发送到以下地址的任何URLhttp://example.com/wp-content/or （“或”后接空格；不区分大小写）在提交的数据中的任何位置紧跟数字（不仅仅是字段值）（例如。an ARM or 30-year fixed-rate mortgage)
从我所能说的一切来看，这是一个令人难以置信的具体问题，在单个网站上的问题。由于复制场景，我猜这是由于一些过于雄心勃勃的反SQL注入代码。
Is there any code present by default in Wordpress that could be causing this problem? 我猜这个问题应该归咎于其他原因（例如防火墙、.htaccess 规则等），但我想我应该向专家核实一下！：）
更新：
我们还观察到了以“[运算符]具有[字符串]”格式发布数据的问题，例如< having x, or having y, and having z, 等等，考虑到HAVING 是一个SQL关键字，我怀疑这是一个配置不当的安全工具的进一步证据。请注意，这些不同的观察结果是在不同的服务器上进行的，因此在这台服务器上并不仅仅是一件很奇怪的事情。我想多个服务器可能配置错误/有严格的安全协议，不过。。。
另一个更新：我又遇到了这个问题。这一次，我将问题POST有效负载简化为字符串<strong>. 任何包含此字符串的已发布数据（与上面的其他条件一致）都会生成404。
最合适的回答,由SO网友:rinogo 整理而成
正如Jeff Mattson所说，数小时的研究和测试表明，这可能是由于mod\\u安全性造成的。我还调查了这可能是由苏霍辛造成的，但我不认为这是罪魁祸首。
事情是这样的。如果我们确认问题是由mod\\u安全性引起的，那么这并没有真正的帮助。我们无法控制运行我们插件的服务器，也无法通过.htaccess 已失败。
幸运的是，隧道尽头有亮光。无论是什么原因导致了问题，几乎可以肯定能够解决问题的修复方法就是简单地修改POST 数据
The solution I plan to implement is to Base62 encode the data that we\'re sending to our plugin. Base64 would probably work as well, but I\'d like to solve this problem once and for all, and due to its limited character set, Base62 is the safer bet when dealing with a neurotic beast like mod_security.
这应该是可行的，因为mod\\u security在提交的数据中查找某些“故障”字符串。我怀疑该模块是否足够复杂，是否可以尝试对提交的数据应用一系列不同的编码（此外，这样做会对性能产生不利影响），因此这几乎可以保证解决我们的问题。
耶！
