HTTP提供了一个简单的质询响应认证框架，它可以被服务器用来质询客户端请求或被客户端用来提供认证信息。它使用不区分大小写的标记作为一个手段去识别认证方案，后面跟随通过那个方案实现认证的额外的必要信息。后者可以是一个逗号分隔的参数列表或一个持有base64编码信息的单个字符序列。

    认证参数是名称=值对，其中名称标记不区分大小写的匹配，每个参数名在每次质询中必须只发生一次。 

    1.      auth-scheme    = token
    3.      auth-param     = token BWS "=" BWS ( token / quoted-string )
    5.      token68        = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="

    68标记语法允许66个非保留的URI字符（RFC3986），加上一些其他的，使得它可以持有一个base64，base64url（URL和文件名安全字母），base32，或base16（16进制）编码，带或不带填充，但排除了空白符（RFC4648）。

    401响应消息被源服务器使用以质询用户代理的认证，包括一个WWW-Authenticate头字段，它至少含有一个适用于被请求资源质询。

    407响应消息被代理使用以质询客户端的认证，包括一个Proxy-Authenticate头字段，它包含至少一个对被请求资源适用于代理的质询。

    1.     challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

    注意：很多客户端解析包含未知方案的质询会失败。这个问题的一个解决办法是先列出良好支持的方案（如”基本”）。

    希望去于一个源服务器认证它自己的用户代理通常，但不是必须的，在收到一个401之后，可以通过在请求中包含Authorization头来实现。

    希望于代理认证它自己的客户端通常，但不是必须的，在接收到一个407之后可以在请求中包含一个Proxy-Authentication头字段来实现。

    Authorization字段值和Proxy-Authorization字段值都包含客户端的资源被请求域的凭证，基于在响应中接收到的质询（可能在过去的某一点上）。当创建它们的值时，用户代理应该通过选择它所认为的最安全的认证方案来挑选质询，并根据需要从用户那里获得凭证。头字段值中的凭证的转移暗示了有关底层连接保密的重大安全考虑，如6.1节描述。

    1.      credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

    在收到一个省略证书的受保护资源，包含无效的证书（例如，错误的密码）或部分证书请求时（例如，当认证方案要求至少超过一次往返），源服务器应该响应一个401响应，其包含一个WWW-Authenticate头字段，带有至少一个（可能是新的）适用于被请求资源的质询。

    同样，在接受到一个忽略了代理凭证或包含无效或部分代理凭证的请求时，要求认证的代理应该生成一个407响应，它包含一个Proxy-Authenticate头字段，带有至少一个（可能是新的）适用于代理的质询。

    接收到一个有效的但还不足以获得访问的质询的服务武器应该响应403状态码（RFC7231，6.5.3节）。

    HTTP没有限制应用程序用这个简单的质询响应框架进行访问认证。额外的机制可以被使用，如在传输层的认证或通过消息封装，并且使用额外的头字段指明认证信息。但是，这种认证机制不再本规范定义。