为什么浏览器不在请求标头中发送是否启用/禁用 javascript 的信息?
这似乎在开发服务器端代码时非常有用。如果您知道浏览器不会使用服务器端的 javascript,那么您可以轻松地适应用户。或者,如果您只是想这样做,请将他们重定向到一个页面,上面写着“嘿...我们需要您为我们的应用程序使用 javascript”等。
有谁知道这是为什么?
It just seems like something that would be really useful when developing server-side code. If you know that the browser won't be using javascript from the server-side, you could easily accommodate the user. Or if you just felt like it, redirect them to a page that says 'hey... we need you to use javascript for our application' etc.
Does anyone know why this is?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
请参阅此处的
标记。
我知道它可能并不理想(我没有足够的经验来区分它),但它确实给了我们足够的灵活性来优雅地降级。
See the
<noscript>
tag, here.I know it's probably not ideal (I don't have enough experience with it to pick it apart) but it certainly gives us enough flexibility to degrade somewhat gracefully.
尽管让服务器在页面渲染开始之前了解浏览器的 JavaScript 功能会很方便,但我可以看到一个奇怪的边缘情况,例如:
As handy as it would be to have your server be aware of your browser's Javascript capability before page rendering began, I can see a strange edge case such as:
我使用的一种方法是拥有一个登陆页面/登录页面。当用户按下登录按钮时,然后使用 javascript 提交结果或在发布登录之前更新隐藏字段。如果 JavaScript 被禁用,那么 JavaScript 将无法工作,因此您可以假设他们已将其关闭。
One way I use is to have a landing page/login page. When the user presses the logon button then use javascript to submit the results or update a hidden field before posting the logon. If javascript is disabled then the javascript will not work and therefore you can assume they have it turned off.
真正的原因是,当 Netscape 推出 JavaScript 时,他们从未想过在 HTTP 标头中提供信息。相反,他们创建了
标记。
The real reason is that when Netscape came out with JavaScript, they never thought to make the information available in the HTTP headers. Instead they created the
<noscript>
tag.我想 Accept 字段可以用于这样的目的,例如“Accept:text/javascript”。但由于它是专有的,IETF 永远不会将其纳入任何标准,因此不太可能进行广泛的适应。到目前为止,网络开发人员已经应对了。
I suppose the Accept field could be used to such a purpose, like "Accept: text/javascript". But since it's proprietary the IETF would never include it in any standards and widespread adaptation is therefore unlikely. Web-developers has coped so far.