406NotAcceptable：是什么及如何解决
原⽂链接参见, ⼯作中偶然碰到的问题，已解决。这是⼀篇很好的参考，遂翻译在此。
406 Not Acceptable: 是什么及如何解决
January 25, 2018 Andrew Powell-Morse
406 Not Acceptable是⼀个HTTP响应状态码，指⽰服务器⽆法实现客户端的⼀个 Accept-标头的请求响应。这通常是⽤户代理（即浏览器）指定⼀个可接受的字符集（通过Accept-Charset）、语⾔（通过Accept-Language）等应响应的结果，并且服务器⽆法提供此类响应。
与⼤多数 HTTP 响应代码⼀样 — 尤其是那些指⽰错误的响应代码 — 406 Not Acceptable 错误代码的原因可能难以跟踪和修复。具有 50 多个状态代码的潜在池，这些代码表⽰客户端、Web 应⽤程序、Web 服务器以及通常有多个第三⽅ Web 服务之间的复杂关系，这导致了在最佳情况下，确定特定状态代码的原因可能是⼀项挑战。
在本⽂中，我们将通过查看可能导致消息的原因，以及⼀些⽤于诊断和调试此错误在您⾃⼰的应⽤程序中出现的错误提⽰来更详细地检查406 Not Acceptable的内容。我们甚⾄会检查⼀些最流⾏的内容管理系统（CMS），以发现可能导致您⾃⼰的⽹站意外⽣成 406 Not Acceptable 的潜在问题区域。让我们钻研⼀
下吧！
服务端-还是客户端?
4xx 类别中的所有 HTTP 响应状态代码都被视为客户端错误响应。此类别与 5xx 分类错误（如我们⼏个⽉前探索的 504 ⽹关超时错误）形成鲜明对⽐，这些错误被视为服务器错误响应。也就是说，出现 4xx 错误并不⼀定意味着问题出在客户端，这⾥的"客户端"是指⽤于访问应⽤程序的 Web 浏览器或设备。通常，如果您尝试在您⾃⼰的应⽤程序中诊断问题，可以⽴即忽略⼤多数客户端代码和组件，如 HTML、级联样式表（CSS）、客户端 JavaScript 等等。这也不仅仅适⽤于⽹站。许多实现时髦⽤户界⾯的智能⼿机应⽤程序实际上由后台的正常 Web 应⽤程序提供⽀持，⽽这些应⽤程序只是对⽤户来说简单地隐藏起来⽽已。
另⼀⽅⾯，服务器可能是 406 Not Acceptable 错误的根本原因。在某些情况下，服务器可能配置错误，并且不正确地处理了请求，这可能导致 406 代码响应和其他有疑问的流量路由问题。我们将在下⾯探讨其中⼀些场景（和潜在的解决⽅案），但请注意，即使 406 Not Acceptable 被视为客户端错误响应，在这个场景下它本质上并不意味着我们可以排除客户端或服务器作为此问题的罪魁祸⾸。在这些场景下，服务器仍然是⽣成 406 Not Acceptable 的⽹络对象，并将其作为 HTTP 响应代码返回给客户端，但可能是客户端以某种⽅式导致这个问题的。
server error翻译从全⾯应⽤备份开始
和任何事情⼀样，最好在开始的时候就安全地玩转起来，⽽不是把事情搞砸，然后不久以后在路上后悔。因此，在尝试对系统进⾏任何修复或更改之前，对你的应⽤程序、数据库以及⽹站或应⽤程序的所有其他组件执⾏完整备份⾄关重要。更妙的是，如果你有能⼒，请创建应⽤程序的完整备份，并将这个备份存储在⾮活动或公众⽆法访问的辅助暂存服务器上。这将为您提供⼀个⼲净的测试场，⽤于测试解决问题的所有潜在修补程序，⽽不会威胁实时应⽤程序的安全性或神圣性。
诊断⼀个406 Not Acceptable 错误
如简介中所述，406 Not Acceptable 表⽰⽤户代理（在⼤多数情况下是 Web 浏览器）请求了有效的资源，但请求包含⼀个特殊的 Accept-标头，该标头向服务器指⽰有效响应只能包含特定类型的信息。下⾯是此类场景的⼏个栗⼦：
⽤户代理可能本地化为服务器⽆法提供的特定区域设置或语⾔。例如，⽤户代理可以使⽤ Accept-Language 请求标头来指定有效的法语语⾔（Accept-Language:fr），但如果服务器⽆法使⽤法语提供响应，则 406 代码可能是唯⼀正确的响应。
⽤户代理可能请求服务器返回特定类型的内容。这些内容类型通常称为 MIME 类型，⽤于定义如纯⽂本
（text/plain）、PNG 图像（image/png）、mp4 视频（video/mp4）等内容。因此，客户端可以在请求中包含 Accept 标头，并定义应由服务器提供的显式MIME 类型（例如，Accept:application/xml）。如果服务器⽆法响应请求的匹配内容类型，则可能需要 406 Not Acceptable 响应。
在 HTTP 请求中可以提供少量其他 Accept- 标头，但绝⼤多数场景与上述类似：⽤户代理需要显式类型的响应，服务器要么提供响应，要么返回 406 代码以指⽰它⽆法实现请求。
客户端故障排除
既然 406 Not Acceptable 是客户端错误响应代码，因此最好⾸先排除可能导致此错误的任何潜在客户端问题。下⾯是⼀些提⽰，⽤于在出现问题的浏览器或设备上尝试下。
检查请求的URL
调试通⽤平台
如果你在得到 406 Not Acceptable 响应的服务器上运⾏常见软件包，则可能需要⾸先查看这些平台的稳定性和功能。最常见的内容管理系统——如 WordPress、Joomla！和 Drupal——通常都是经过精⼼测试的，但⼀旦您开始对基础扩展或 PHP 代码（这个语⾔⼏乎⽤在所有现代内容管理系统）进⾏了修改，将很容易导致不可预见的问题，进⽽导致 406 Not Acceptable 错误。
下⾯有⼏个提⽰，旨在帮助您解决这些流⾏的软件平台故障。
回滚最近升级
如果您最近刚好在 406 Not Acceptable 错误出现之前更新了内容管理系统本⾝，您可能需要考虑回滚到在⼯作正常时安装的早期版本。同样，您最近升级的任何扩展或模块也可能导致服务器端问题，因此还原到这些扩展或模块的早期版本也可能有所帮助。要获得此任务的帮助，只需使⽤搜索"降级 [平台名称]"然后跟进即可。然鹅，在某些情况下，某些 CMSs 并不真正提供版本降级功能，这表明他们认为基本应⽤程序以及发布的每个新版本都极其稳定且⽆错误。对于较流⾏的平台，典型情况就是如此，所以如果您不到将平台还原到旧版本的简单⽅法，请不要害怕。
卸载新扩展、模块或插件
根据您的应⽤程序使⽤的特定内容管理系统，这些组件的确切名称将有所不同，但它们在每个系统中都具有相同的⽤途：改进平台的功能和特性，使其超出其通常的预期。但请注意：这些扩展或多或少可以完全控制系统，并⼏乎可以进⾏任何更改，⽆论是对 PHP 代码、HTML、CSS、JavaScript 还是数据库。因此，卸载最近可能添加的任何新扩展可能是明智的。再说⼀次，通过搜索这些扩展的名称以获取这个进程的官⽅⽂档和协助。
检查意外的数据库更改
值得注意的是，即使您通过 CMS 仪表板卸载了扩展，也不保证该扩展所做的更改已完全还原。对于许多 WordPress 扩展来说尤其如此，这些扩展在应⽤程序中提供全权委托，包括数据库的完全访问权限。除⾮扩展作者在代码中显式编码此类内容，否则在某些场景下，扩展可能会修改不"属于"扩展本⾝，⽽是由其他扩展（甚⾄基本 CMS 本⾝）创建和管理的数据库记录。在这些情况下，扩展可能不知道如何还原对数据库记录的更改，因此在卸载期间将忽略此类内容。诊断此类问题可能⽐较棘⼿，但我本⼈多次遇到此类情况，因此，假设您有理由相信扩展可能是 406 Not Acceptable 的罪魁祸⾸，因此，您的最佳操作⽅案是打开数据库，⼿动查看可能由扩展修改的表和记录。
最重要的是，不要害怕搜索你的问题。尝试搜索与您的问题相关的特定术语，例如应⽤程序的 CMS 名称随同 406 Not Acceptable。你很有可能会到经历过同样问题的⼈。
服务器端的故障排除
如果您未运⾏ CMS 应⽤程序——或者即使您运⾏了 CMS 应⽤程序，但您确信 406 Not Acceptable 与该应⽤程序⽆关——下⾯是⼀些其他提⽰，可帮助您解决在服务器端可能导致的此类问题。
确认您的服务器配置
您的应⽤程序可能在使⽤两个最流⾏的 Web 服务器软件之⼀ Apache 或 nginx 的服务器上运⾏。在发
布时，这两个⽹络服务器软件占了世界上所有⽹络服务器软件的 84%！因此，您可以采取的第⼀步，以确定是什么可能导致这些 406 Not Acceptable 响应代码是检查您的 Web 服务器软件的配置⽂件是否⽆意的重定向或请求处理指令。
要确定您的应⽤程序正在使⽤哪个Web 服务器，您需要查⼀个密钥⽂件。如果您的 Web 服务器是 Apache，则在⽹站⽂件系统的根⽬录中查 .htaccess ⽂件。例如，如果您的应⽤程序位于共享主机上，则可能具有与托管帐户关联的⽤户名。在这种情况下，应⽤程序根⽬录通常位于 /home//public_html/的路径上，因此 .htaccess ⽂件将在 /home//public_html/.htaccess 处。
如果到 .htaccess ⽂件，然后在⽂本编辑器中打开该⽂件，并查使⽤ RewriteXXX 指令的⾏，这些指令是 Apache 中mod_rewrite模块的⼀部分。但是，涵盖这些规则如何⼯作完全超出了本⽂的范围，但基本概念是，RewriteCond 指令定义了⼀个基于⽂本的模式，该模式将与输⼊的 URL 匹配。如果站点的访问者请求了匹配的 URL，则遵循⼀个或多个 RewriteCond 指令的 RewriteRule 指令⽤于执⾏请求到相应URL 的实际重定向。
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/users/json/?.*$
RewriteCond %{HTTP_ACCEPT} !application/json
RewriteRule ^(.*)$ airbrake.io/users/json$1 [R=406,L]
请注意RewriteRule末尾的 R=406 标志，该标志明确声明响应代码应为 406，向⽤户代理指⽰资源存在，但⽆法实现显式 Accept- 标头。因此，如果您在 .htaccess ⽂件中发现任何看似⾮我同类的奇怪的 RewriteCond 或 RewriteRule 指令，请尝试暂时注释掉它们（使⽤ # 字符前缀），然后重新启动 Web 服务器以查看这是否解决了问题。
server {
listen 80;
listen 443 ssl;
server_name airbrake.io;
location /users/json
{
if ($http_accept != application/json)
{
return 406 airbrake.io/users/json$request_uri;
}
}
}
请查看 f ⽂件，了解包含 406 标志的任何异常指令或⾏。在重新启动服务器之前注释掉任何异常，以查看问题是否得到解决。
每种不同类型的 Web 服务器的配置选项可能巨⼤差异，因此，我们将仅列出⼀些流⾏的项⽬，以便为您提供⼀些资源，具体取决于您的应⽤程序在哪种类型的服务器上运⾏：
Apache
Nginx
IIS
Node.js
Apache Tomcat
查看⽇志
⼏乎每个 Web 应⽤程序都会保留某种形式的服务器端⽇志。应⽤程序⽇志通常是应⽤程序所执⾏操作的历史记录，例如请求了哪些页⾯、它连接到哪些服务器、它提供的哪些数据库结果，等等。服务器⽇志与运⾏应⽤程序的实际硬件相关，并且通常会提供有关所有已连接服务的运⾏状况和状态的详细信息，甚⾄仅提供服务器本⾝的详细信息。如果您使⽤的是 CMS，搜索"⽇志平台名称"；如果您正在运⾏⾃定义应⽤程序，则使⽤"⽇志编程语⾔"和"⽇志操作系统"来进⾏搜索，以获取有关查出现问题相关⽇志的详细信息。
调试应⽤程序代码或脚本
如果所有其他操作都失败，可能是应⽤程序中某些⾃定义代码中的问题导致了该问题。尝试通过⼿动调试应⽤程序以及分析应⽤程序和服务器⽇志来诊断问题可能来⾃何处。理想情况下，将整个应⽤程序的副本复制到本地开发计算机，并执⾏分步调试过程，这将允许您重新创建发⽣ 406 Not Acceptable 的确切场景，并在错误发⽣时查看应⽤程序代码。
⽆论原因是什么——即使您这次设法修复了它——在您⾃⼰的应⽤程序中出现类似 406 Not Acceptable 的问题，他们发⽣的时刻都是您可能想要实现错误管理⼯具的良好指⽰，它将帮助您⾃动检测错误并会提醒你。Airbrake 的错误监控软件可为您的所有开发项⽬提供实时错误监控和⾃动异常报告。Airbrake 最先进的 Web 仪表板可确保您收到有关应⽤程序运⾏状况和错误率的全天候状态更新。⽆论您从事什么⼯作，Airbrake 都可以轻松与所有最流⾏的语⾔和框架集成。此外，Airbrake 还可以轻松⾃定义异常参数，同时让您完全控制活动错误滤清系统，因此您只收集最重要的错误。
现在就来看看 Airbrake 的错误监控软件吧，亲⾃了解为什么这么多世界上最好的⼯程团队使⽤ Airbrake 来彻底改变其异常处理实践！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。