我应该在基于html的登录表单上返回http 401状态代码吗？

我应该在基于html的登录表单上返回http 401状态代码吗？该页面是专用的登录表单，没有任何其他有意义的内容，只是网站框架。但是，URL可以用于确实具有有意义内容但需要登录的页面。请注意，此设置仅返回状态码401，不会提示用户进行基本身份验证。

查看标准，看来401对于基于html的登录表单来说是不合适的状态代码。但是，我从未经历过或听说过这样做有任何不良后果。

发送401时，“响应必须包含一个WWW-Authenticate标头字段（第14.47节），其中包含适用于所请求资源的质询。”

这里提到的要求：

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身份验证而在http级别进行身份验证吗？

如您所述，RFC 2616要求401响应随附一个RFC 2617 WWW-Authenticate标头。我想您可以通过发送伪造的标头从技术上遵守该要求：

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

但我不知道如果浏览器收到401响应，但不包含他们不理解的挑战，该怎么办。我假设大多数（如果不是全部的话）都会向用户呈现请求正文（如RFC 2616所述，如果身份验证失败，则应这样做），但是RFC似乎都没有这么明确地说，因此它们可能只是显示一般错误消息代替。

一个可能的选择（如果您不想像其他所有人一样使用200响应），则可以使用403禁止状态代码。这是一个广泛使用的响应代码，据我所知，几乎所有交互式用户代理（即浏览器，而不是搜索引擎或下载管理器）都应该通过将内容呈现给用户来对此做出反应，至少如果足够长的话。

尽管403状态代码的描述说“无助”，但在上下文中应将IMO理解为是指RFC 2617身份验证或类似的协议级授权机制。就浏览器而言，它不知道提交表单和接收Cookie作为响应算作“授权”还是其他。

一种更常用的机制是通过将原始URL作为参数传递，以临时重定向到单独的登录页面来响应未认证的请求，以便在成功认证之后将用户重定向回该页面。但是，请注意，幼稚的实现可能允许恶意程序制作登录链接，该链接将在用户登录后将用户重定向到任意URL。如果这可能是安全问题，则应采取措施阻止它，例如，仅接受返回URL匹配已知的安全模式，或通过使用消息身份验证代码保护返回URL 来防止修改。

无论如何，如果您在登录后使用HTTP cookie来存储身份验证令牌，则应在响应中（身份验证之前和之后）包括一个Vary标头，以防止进行不适当的缓存，如中所述Vary: Cookie。

首先，如果该页面需要登录，那么您可能应该通过robots.txt阻止它

其次，如果机器人确实到达了页面，则出现401错误是正确的。

状态代码可能对非人类[以及某些浏览器有用吗？]

通过登录方法独立发送正确的标头

例如，将来您可能需要编写包装器客户端（而不是Web浏览器），该包装器仅通过请求页面标题（而不是html代码的全部）来简单地对自身进行身份验证

您可以使用与用户列表相同的数据库使用两种方法来实现您的登录应用程序