查看标准，看来401对于基于html的登录表单似乎是不合适的状态代码。但是，我从来没有经历过或听说过这样做有任何不良后果。资源。“
此处提到的要求：
http://tools.ietf.org/html/rfc2616#section-10.4.2
在此处详细介绍：
http://tools.ietf.org/html/rfc2617#section-3.2.1
我知道我可以采用多种方法来解决搜索引擎问题可以说服他们根据登录表单的存在来为页面建立索引或不建立索引，但是我更喜欢使用http状态代码，尤其是401，因为它的定义似乎很符合WWW-Authenticate标头要求。
在这种情况下，为什么我不应该使用401？从语义上说，未在http级别被授权与在应用程序级别被授权之间有什么区别？显然，您可以同时拥有这两种功能，但是难道不是为了在应用程序级别不轻松实现HTTP级别的身份验证吗？
#1 楼
如您所述，RFC 2616要求401响应随附一个RFC 2617 WWW-Authenticate标头。我想您可以通过发送如下伪造的标头来从技术上满足该要求：他们了解的挑战。我假设大多数（如果不是全部的话）会向用户呈现请求正文（如RFC 2616所述，如果身份验证失败，则应该这样做），但是RFC似乎都没有这么明确地说，因此它们可能只是显示一般错误消息相反。
一种可能的选择（如果您不想像其他所有人一样使用200响应），则可以使用403 Forbidden状态代码。这是一种广泛使用的响应代码，据我所知，几乎所有交互式用户代理（即浏览器，而不是搜索引擎或下载管理器）都应该通过将内容呈现给用户来对此做出反应，至少如果足够长的话。级别授权机制；就浏览器而言，它不知道提交表单和接收cookie作为响应算作“授权”还是其他。
一种更常用的机制是通过将原始URL作为参数传递，以临时重定向到单独的登录页面来响应未经身份验证的请求，以便在成功进行身份验证后将用户重定向回该URL。但是，请注意，幼稚的实现可能允许恶意程序制作登录链接，该链接将在登录后将用户重定向到任意URL。通过仅接受与已知安全模式匹配的返回URL，或通过使用消息身份验证代码保护返回URL来防止修改。
无论如何，如果您在之后使用HTTP cookie存储身份验证令牌，登录时，应在响应中（身份验证之前和之后）包括Vary标头，以防止进行不适当的缓存，如
Vary: Cookie所示。#2 楼
首先，如果该页面需要登录，则可能应该由robots.txt阻止。其次，如果机器人确实到达该页面，则出现401错误是正确的。
#3 楼
状态代码可能对非人类[和某些浏览器有用？ ]通过登录方法独立地发送正确的标头
，例如，将来您可能需要编写一个包装客户端（而不是Web浏览器）仅通过请求页面标题（而不是整个html代码）进行身份验证
您可以使用与用户列表相同的数据库使用这两种方法来实现登录应用程序