浏览器和服务器是否实际使用HTTP内容协商？

我现在正在学习。我已经了解了客户端和服务器协商请求内容表示的基本方式

不过，我不知道内容谈判到底有什么好处现实世界的浏览器是否在积极使用这些信息？我知道他们正在发送一些标题，如

Accept

，但其内容和含义似乎定义模糊

我还想知道现实世界的web应用程序是否可以利用HTTP内容协商一个现实的web应用程序会根据这些标题返回不同的数据吗？一个服务器如何根据

q因子

做出有意义的决定

我的目标是了解真正的web应用程序在这方面是如何工作的，这样我就可以更好地决定我想学习和使用HTTP内容协商的哪些部分

---

也许答案只是，这在实践中没有被使用，这对我来说是一个有效的答案。用例的具体示例也会有所帮助。

是的。它肯定用于多语言页面（为法语和英语用户显示不同页面的网站）

---

我还可以想象，版本控制系统的某些web界面可以使用

Accept:

标题来显示（在显示某些C源文件时）原始C文件或其HTML格式的版本。

它肯定被大量使用，例如用于协商格式（使用“Accept”，例如用于image/webp），压缩编码（使用“接受编码”，如brotli）或不同的语言（使用“接受语言”）。

一些API允许基于请求的内容类型使用JSON或XML或其他数据格式。如果能够满足请求，则由处理请求的服务器决定。。。。这将是最糟糕的选择之一，伊姆霍。不同的语言版本应该有不同的URL。根据Accept语言自动将用户重定向到其中一个是可以的，但是在完全相同的URL下提供两个语言版本会带来麻烦。@JulianReschke例如搜索引擎。。。即使他们确实发送了一个Accept Language标头，并且意识到您在同一URL下有不同的语言版本，但仍然存在一个问题，即如果我的浏览器发送了不同的Accept Language标头，搜索引擎在结果中显示的内容可能与我在页面上实际找到的内容不同。而书签、向其他人发送链接等基本上也存在同样的问题。@CBroe-书签也可以是一项功能，不过-取决于使用情况-我同意为不同语言提供额外的不同URI是好的，您可以使用“内容位置”在响应中指定它们。@JulianReschke是的，但是，如果我们首先有不同语言的不同URL，那么服务器端内容协商有什么实际意义呢？正如我所说的，我可以看到自动重定向到其中一个语言版本是有意义的，因为这是关于用户可能想要什么语言的“最佳猜测”（这实际上与浏览器发送的Accept语言相匹配是最好的情况——但实际上，随着人们访问国外网吧等，情况并不总是如此。）