Squid Web Cache Wiki

Squid Web Cache 文档

🔗 Feature: Squid 的 HTTP/1.1 转换进展？

🔗 详细信息

:warning: 信息未更新。空条目需要与代码进行核对。

  已支持。预计可正常工作。已通过第三方测试验证。可能指示了最低版本。
  缺失，待完成。已通过第三方测试。可能指示了上次测试版本。
:rage: 开发人员预计其可工作。未获第三方确认。
:frowning: 缺失，但可选
2.x 3.x ID 需求类型 章节 需求 备注
:rage: :rage: 1 必需 (REQUIRED) 2.1 处理隐含的 ` LWS = [CRLF] 1*( SP | HT ) `  
:rage: :rage: 2 必需 (REQUIRED) 2.2 在解释之前，将报头中的 CRLF 折叠成一个长报头  
:rage: :rage: 3 必须 (MUST) 3.1 将 HTTP-Version 解析为两个多位数整数  
:frowning: :frowning: 4 应该 (SHOULD) 3.1 一旦我们符合条件，就在消息中使用 HTTP/1.1 发送  
:frowning: :frowning: 5 必须 (MUST) 3.1 在与 HTTP/1.0 不兼容的消息中使用 HTTP/1.1 发送  
:rage: :rage: 6 不得 (MUST NOT) 3.1 发送大于 squid 本身的 HTTP 版本。（当且仅当 squid 符合 rfc 2616 的条件时，它才是 1.1） 当我们支持所有 http/1.1 时，发送 http/1.1
:rage: :rage: 7 必须 (MUST) 3.1 将请求从大于 squid 支持的版本降级到 squid 支持的版本，或返回错误，或切换到隧道行为 降级协议号并解码 TE。仅尝试了少量降级请求。
:rage: :rage: 8 必须 (MUST) 3.1 将客户端请求升级到 squid 支持的最高 HTTP 版本。 转换可能涉及更改报头字段，从而破坏涉及的版本；HNO - 8: 如果启用了对 0.9 的支持（并已修复），HTTP/0.9 将升级到 HTTP/1.0。
:frowning: :frowning: 9 必须 (MUST) 3.1 以相同主版本的 HTTP 响应旧客户端请求。即，1.x 客户端必须收到 1.x 响应，无论 squid 到那时是否是 2.x 代理 来自 squid 的所有 3.x 响应都使用 squid 当前的 http 版本。2.x 有 upgrade_http0.9，它将 0.9 保留在它们自己的主版本中。
:rage: :rage: 10 必须 (MUST) 3.2.1 处理提供的任何资源的 URI（读取的代理）  
4KB 8KB 11 应该 (SHOULD) 3.2.1 如果我们允许长 GET 请求，则处理无界长度的 URI 我们为 URI 设置了上限
    12 应该 (SHOULD) 3.2.1 对于比我们实际能处理的更长的 URI，返回 414 处理超过 255 字节的 URI 时要谨慎 - 旧客户端或下游代理可能会出错。Hno - 我们目前返回其他错误代码
:rage: :rage: 13 应该 (SHOULD) 3.2.2 避免在生成的 URL 中使用 IP 地址 使用了 squid 的主机名
    14 必须 (MUST) 3.2.2 在没有 abs_path 的 http url 中添加 /；并在生成请求时包含 / 发送到源时完成，发送到另一个代理时未完成
    15 不得 (MUST NOT) 3.2.2 更改带有 FQDN 的请求中的主机名 重定向器可以违反此规则
:rage: :rage: 16 可能 (MAY) 3.2.2 在 squid 收到的请求中，将 squid 的域名添加到不是完全限定的主机名中 append_domain
    17 应该 (SHOULD) 3.2.3 通过对整个 URI 进行区分大小写的字节到字节比较来比较 URI。 空的或缺失的端口等同于该资源的默认端口；空的 abs_path =”/”
    18 必须 (MUST) 3.2.3 不区分大小写地比较 URI 中的主机名  
    19 必须 (MUST) 3.2.3 不区分大小写地比较 URI 中的方案名称  
    20 必须 (MUST) 3.2.3 在比较 URI 时，将 % HEX HEX 编码的字符与保留集和不安全集之外的字符进行匹配 例如，*http://abc.com:80/~smith/home.html;* *http://ABC.com/~smith/home.html;* *http://ABC.com:/~smith/home.html* 匹配
:rage: :rage: 21 必须 (MUST) 3.3.1 处理 HTTP/1.0 的三种日期格式 鼓励健壮性 :smile:
:rage: :rage: 22 必须 (MUST) 3.3.1 仅以 rfc 1123 格式生成日期  
:rage: :rage: 23 必须 (MUST) 3.3.1 所有日期都以 GMT (UTC) 时间生成。  
:rage: :rage: 24 必须 (MUST) 3.3.1 读取 asctime 格式时假定为 GMT 时间  
:rage: :rage: 25 必须 (MUST) 3.3.1 除了语法中明确包含的之外，不在 HTTP-date 格式中添加 LWS  
:rage: :rage: 26 必须 (MUST) 3.4 在使用 MIME 字符集时，指定与 MIME 字符集名称相关的映射 错误页面指定 charset & 可能还有其他地方
:rage: :rage: 27 应该 (SHOULD) 3.4 将 MIME 字符集的使用限制在 IANA 注册表定义的字符集中  
:rage: :rage: 28 可能 (MAY) 3.4.1 即使字符集是 ISO-8559-1，也包含 charset 参数  
    29 应该 (SHOULD) 3.4.1 当我们知道不会混淆客户端时，即使字符集是 ISO-8559-1，也包含 charset 参数 未完成
    30 必须 (MUST) 3.4.1 对于“客户端”，尊重发送者提供的 charset 标签。  
    31 不应该 (SHOULD NOT) 3.5 创建带有 Content-Encoding: identity 的响应 现在应该执行
不适用 不适用 32 应该 (SHOULD) 3.5 向 IANA 注册新的 content-coding 值标记  
不适用 不适用 33 应该 (SHOULD) 3.5 发布符合 content coding 目的（根据第 3.5 节）的新 content-coding 值标记的规范  
    34 必须 (MUST) 3.6 当应用传输编码时，在传输编码集中包含“chunked”，除非消息通过关闭连接来终止。 hno - 检查 te 分支
    35 不得 (MUST NOT) 3.6 将“chunked”应用于消息正文一次以上 hno - 检查 te 分支
不适用 不适用 36 应该 (SHOULD) 3.6 向 IANA 注册新的传输编码（如 3.5 节关于 content-codings）  
    37 应该 (SHOULD) 3.6 当收到 squid 无法理解其 transfer-codings 的客户端实体正文时，返回 501 并关闭连接。 hno - 检查 te 分支
    38 不得 (MUST NOT) 3.6 将传输编码（TE 或 Transfer-Encoding 报头）发送到 HTTP/1.0 客户端 hno - 检查 te 分支
    39 可选 (OPTIONAL) 3.6.1 在发送分块传输编码的消息后发送 trailer hno - 检查 te 分支
    40 不得 (MUST NOT) 3.6.1 除非 a) 请求包含指示 trailers 在 transfercoding 中可接受的 TE 报头（参见 14.39）或 b) 服务器是源（并且可以意译），否则将报头放入 trailer（trailer 不需要用于响应） hno - 检查 te 分支
    41 必须 (MUST) 3.6.1 理解“chunked”传输编码 hno - 检查 te 分支
    42 必须 (MUST) 3.6.1 忽略不理解的 chunk-extensions hno - 检查 te 分支
:rage: :rage: 43 不得 (MUST NOT) 3.7 在 media-types 的类型和子类型之间，或在属性和值之间使用 LWS 现在为 squid 生成的报头执行此操作
    44 应该 (SHOULD) 3.7 在发送到旧应用程序（< HTTP/1.1）时，仅在类型/子类型定义需要时才使用 media types  
:rage: :rage: 45 必须 (MUST) 3.7.1 以规范 media-type 形式表示实体正文（“text”类型除外）。  
:rage: :rage: 46 必须 (MUST) 3.7.1 在对实体正文进行 content-coding 之前，以规范 media-type 形式表示实体正文（“text”类型除外）  
    47 必须 (MUST) 3.7.1 使用适当的 charset 值标记非 ISO-8859-1 的字符集中的数据。 有关兼容性说明，请参阅 rfc 2616 第 3.4.1 节
    48 必须 (MUST) 3.7.2 在 multipart media types 的 media type 值中包含 boundary 参数 hno - squid 不生成或触及 multipart 条目。Rbc - 我们可能需要根据 TE 内容进行此操作。嗯，
    49 必须 (MUST) 3.7.2 在 multipart 消息中仅使用 CRLF 来表示 body-parts 之间的换行符。 hno - squid 不生成或触及 multipart 条目。Rbc - 我们可能需要根据 TE 内容进行此操作。嗯，
    50 必须 (MUST) 3.7.2 使 multipart 消息的 epilogue 为空 hno - squid 不生成或触及 multipart 条目。Rbc - 我们可能需要根据 TE 内容进行此操作。嗯，
    51 不得 (MUST NOT) 3.7.2 传输 multipart 消息的 epilogue（即使已提供） hno - squid 不生成或触及 multipart 条目。Rbc - 我们可能需要根据 TE 内容进行此操作。嗯，
    52 应该 (SHOULD) 3.7.2 在接收 multipart 消息正文时，遵循 MIME 代理的行为。  
    53 必须 (MUST) 3.7.2 将未识别的 multipart 子类型视为“multipart/mixed” 有关 multipart/form-data 的定义，请参阅 rfc 1867
    54 应该 (SHOULD) 3.8 使用简短、有针对性的 product-tokens  
    55 不得 (MUST NOT) 3.8 使用 product tokens 进行广告或非必需信息  
    56 可能 (MAY) 3.8 在 product-version 中使用任何 token 字符  
    57 应该 (SHOULD) 3.8 仅为特定版本使用 product-version tokens  
    58 应该 (SHOULD) 3.8 仅在更改版本号时更改 product 值的 product-version 部分  
    59 不得 (MUST NOT) 3.9 在质量值的小数点后生成超过 3 位数字  
    60 应该 (SHOULD) 3.9 将用户配置限制在质量值的 3 位数字  
:neutral_face: :rage: 61 必须 (MUST) 3.10 在 accept-language 和 content-language 字段中使用 rfc 1766 语言标签  
    62 可能 (MAY) 3.11 仅当两个资源通过字节相等性等效时，才为它们提供相同的“强”实体标签  
    63 可能 (MAY) 3.11 仅当两个资源等效且可以无显著语义更改地进行替换时，才为它们提供相同的“弱”实体标签  
    64 必须 (MUST) 3.11 提供实体标签时，为与特定资源关联的所有实体版本提供唯一的实体标签  
    65 可能 (MAY) 3.11 为不同的资源 URI 提供相同的实体标签值 - 请注意，这并不意味着跨资源实体的等效性  
    66 可能 (MAY) 3.12 忽略使用“bytes”以外的单位指定的未识别范围  
    67 应该 (SHOULD) 4.1 在预期 Request-Line 的地方忽略空行  
    68 不得 (MUST NOT) 4.1 在请求前后添加额外的 CRLF  
    69 可能 (MAY) 4.2 在报头字段值前添加 LWS - 尽管首选单个 SP  
    70 必须 (MUST) 4.2 在报头字段的额外行前添加单个 SP 或 HT  
    71 可能 (MAY) 4.2 将字段值中的 LWS 替换为单个 SP  
    72 可能 (MAY) 4.2 删除报头字段的开头或结尾的 LWS  
    73 建议 (recommendation) 4.2 先发送 general-headers，然后是 request/response headers，最后是 entity-headers  
    74 必须 (MUST) 4.2 在生成具有相同 field-name 的多个消息报头字段时，客户端或下游应能通过按接收顺序附加 “, field-value” 来组合生成一个长报头字段  
    75 不得 (MUST NOT) 4.2 更改具有相同 field-name 的多个消息报头的顺序  
    76 必须 (MUST) 4.3 在传输消息时，使用 Transfer-Encoding 指示使用的任何传输编码。  
:rage: :rage: 77 可能 (MAY) 4.3 沿请求链添加或删除 Transfer-Encoding（例如，接收消息为普通实体正文，然后通过 gzip 进行传输编码以向下游传输）  
    78 不得 (MUST NOT) 4.3 如果请求方法不允许，则在请求中包含消息正文  
:rage: :rage: 79 应该 (SHOULD) 4.3 读取并转发任何请求中的消息正文。  
    80 应该 (SHOULD) 4.3 当请求方法的语义未定义消息正文时，忽略消息正文  
  :rage: 81 不得 (MUST NOT) 4.3 在响应 HEAD 请求时包含消息正文  
    82 不得 (MUST NOT) 4.3 在 1xx 响应中包含消息正文  
    82 不得 (MUST NOT) 4.3 在 204 响应中包含消息正文  
    82 不得 (MUST NOT) 4.3 在 304 响应中包含消息正文  
:rage: :rage: 83 必须 (MUST) 4.3 在所有其他响应中包含消息正文，尽管它可以是零长度的  
    84 必须 (MUST) 4.4 假定在没有消息正文的响应（例如 1xx、204、304 和 HEAD 请求）中，报头字段后的第一个空行终止消息  
    85 不得 (MUST NOT) 4.4 如果 entity-length 和 transfer-length 不相等，则发送 Content-Length 报头  
    86 必须 (MUST) 4.4 如果收到 Transfer-Encoding 报头，则忽略 Content-Length 报头  
    87 不得 (MUST NOT) 4.4 发送 multipart/byteranges 媒体类型，除非我们知道接收方可以解析它。 包含多个字节范围说明符的 Range 报头来自 1.1 客户端，这表明客户端可以解析这些响应
    88 必须 (MUST) 4.4 在将 multipart/byteranges 类型的响应发送到 1.0 代理（该代理转发来自理解该类型的客户端的请求）时，通过以下方式之一来分隔响应消息： 1) 如果没有定义消息正文（参见 4.3）的第一个空行，3) Content-Length 报头或 5) 关闭连接  
    89 必须 (MUST) 4.4 在包含消息正文的请求中包含 Content-Length 报头，除非已知服务器符合 1.1。  
    90 应该 (SHOULD) 4.4 如果无法确定请求消息的长度，则返回 400 bad request，或者如果希望强制接收有效的 content-length，则返回 411。  
    91 不得 (MUST NOT) 4.4 包含 Content-Length 和非 identity 传输编码。  
    92 必须 (MUST) 4.4 如果收到非 identity Transfer-Encoding，则忽略 Content-Length 报头。（也许是为了 TE 而不是 Transfer-Encoding？？）  
    93 必须 (MUST) 4.4 如果我们充当用户代理（即“客户端”） - 当收到无效长度并被检测到时，通知用户 - 即 Content-Length 与消息正文中的字节数不匹配。  
    94 必须 (MUST) 4.4 在发送允许消息正文的响应并包含 Content-Length 时，其值必须与消息正文中的字节数匹配  
    95 必须 (MUST) 4.5 将未识别的报头字段视为实体报头字段  
    96 应该 (SHOULD) 5.1.1 如果请求方法已识别但未允许，则返回 405  
    97 应该 (SHOULD) 5.1.1 如果请求方法未实现，则返回 501  
    98 必须 (MUST) 5.1.1 支持 squid 生成页面的 GET 和 HEAD  
    99 必须 (MUST) 5.1.1 根据 rfc 2616 实现除 GET 和 HEAD 之外的其他方法  
    100 必须 (MUST) 5.1.1 识别所有 squid 服务器名称，包括任何别名、本地变体和数字 IP 地址  
    101 必须 (MUST) 5.1.1 接受所有请求的绝对 URI。  
:rage: :rage: 102 可能 (MAY) 5.1.1 将请求转发给其他代理或源服务器。  
    103 必须 (MUST) 5.1.2 在解释请求之前，使用 % HEX HEX 格式解码 URI。  
    104 应该 (SHOULD) 5.1.2 向无效的 Request-URIs 返回适当的状态码  
    105 不得 (MUST NOT) 5.1.2 在透明模式下；重写 Request-URI 中的 abs_path（除了将 null abs_path 替换为“/”）  
    106 必须 (MUST) 5.2 对于绝对 Request-URI，忽略请求中的任何 host 报头字段  
    107 必须 (MUST) 5.2 对于带有 host 报头的非绝对 Request-URI，使用 host 报头字段的值  
    108 必须 (MUST) 5.2 对于没有 host 报头的非绝对 Request-URI，返回 400  
    109 不得 (MUST NOT) 5.2 生成带有 CR 或 LF 的响应，但不在状态行末尾  
    110 必须 (MUST) 6.1 理解状态码的类别（第一位）并将未识别的响应视为 x00。  
    111 不得 (MUST NOT) 6.1 缓存具有未识别状态码的响应  
    112 可能 (MAY) 7 除非被请求方法或响应代码另有限制，否则传输实体  
:rage: :rage: 113 必须 (MUST) 7.1 在透明模式下：转发未识别的报头字段  
:rage: :rage: 114 应该 (SHOULD) 7.2.1 为带有实体正文的生成 HTTP/1.1 消息包含 Content-Type 报头  
    115 应该 (SHOULD) 7.2.1 将未知媒体类型视为 application/octet-stream  
:rage: :rage: 116 应该 (SHOULD) 8.1.1 实现 HTTP/1.1 持久连接  
  :frowning: 117 应该 (SHOULD) 8.1.2 假定 http/1.1 服务器即使在收到服务器错误响应后仍会维护持久连接  
  :rage: 118 不得 (MUST NOT) 8.1.2 在服务器错误响应后，在连接上发送更多请求  
  :rage: 119 可能 (MAY) 8.1.2.1 假定 HTTP/1.1 客户端打算维护持久连接，除非在请求中收到了带有 token close 的 Connection 报头  
  :rage: 120 应该 (SHOULD) 8.1.2.1 如果我们希望在发送响应后立即关闭客户端连接，则发送带有 token close 的 Connection 报头  
  :rage: 121 可能 (MAY) 8.1.2.1 期望连接保持打开状态 - 但根据服务器响应决定（它是否有带有 token close 的连接报头）？  
  :rage: 122 应该 (SHOULD) 8.1.2.1 如果我们只想发送一个请求然后关闭服务器端连接，则发送带有 token close 的 Connection 报头  
    123 不应该 (SHOULD NOT) 8.1.2.1 假定为 HTTP/1.1 之前的版本维护持久连接，除非显式信号。  
    124 必须 (MUST) 8.1.2.1 始终创建具有自定义消息长度的消息  
    125 可能 (MAY) 8.1.2.2 将请求管道化到上游服务器  
    126 必须 (MUST) 8.1.2.2 按接收顺序将响应发送到管道化请求  
    127 应该 (SHOULD) 8.1.2.2 如果我们假定与服务器的持久连接，并在连接后立即进行管道化，请准备好在第一次管道化尝试失败时重试连接  
    128 不得 (MUST NOT) 8.1.2.2 当重试失败时（如果我们假定与服务器的持久连接，并在连接后立即进行管道化，请准备好在第一次管道化尝试失败时重试连接），在知道连接是持久连接之前进行管道化  
    129 必须 (MUST) 8.1.2.2 准备好在服务器在发送所有管道化请求之前关闭连接时，重新发送请求  
    130 不应该 (SHOULD NOT) 8.1.2.2 管道化非幂等方法或非幂等方法序列。  
    131 应该 (SHOULD) 8.1.2.2 在收到上一个请求的响应状态后，等待发送非幂等请求 注意：这对我们来说可能不是问题。
  :rage: 132 建议 (recommendation) 8.1.3 正确实现 Connection 报头字段  
  :rage: 133 必须 (MUST) 8.1.3 使用不同的方式与客户端和上游服务器分别处理持久连接  
    134 不得 (MUST NOT) 8.1.3 与 HTTP/1.0 客户端建立 HTTP/1.1 持久连接  
  :rage: 135 应该 (SHOULD) 8.1.4 在持久连接超时时，通过正常的关闭来终止传输连接  
  :rage: 136 应该 (SHOULD) 8.1.4 监控持久连接的关闭信号并作出相应响应  
:rage: :rage: 137 可能 (MAY) 8.1.4 随时可以关闭任何连接。  
    138 必须 (MUST) 8.1.4 能够从异步关闭事件中恢复。  
    139 应该 (SHOULD) 8.1.4 在异步关闭事件后，重新打开传输连接并自动重传中止的序列，只要请求是幂等的  
    140 不得 (MUST NOT) 8.1.4 在异步关闭事件后，重新打开传输连接并自动重传中止的序列，如果请求是非幂等的  
:rage: :rage: 141 应该 (SHOULD) 8.1.4 如果可能，始终每个连接响应至少一个请求  
:rage: :rage: 142 不应该 (SHOULD NOT) 8.1.4 在传输响应的中间关闭连接，除非怀疑网络或客户端故障  
    143 应该 (SHOULD) 8.1.4 对于客户端程序 - 限制维护到给定服务器的同时连接数。  
    144 不应该 (SHOULD NOT) 8.1.4 对于客户端程序 - 与任何给定服务器或代理保持超过 2 个连接  
    145 应该 (SHOULD) 8.1.4 对于代理 - 与另一个服务器或代理最多使用 2*N，其中 N 是同时连接的活动用户数  
    146 应该 (SHOULD) 8.2.1 维护持久连接并使用 TCP 流量控制来解决链路拥塞，而不是突然终止连接  
    147 应该 (SHOULD) 8.2.2 发送消息正文时，监控网络连接错误。  
    148 应该 (SHOULD) 8.2.2 发送消息正文时，如果检测到网络错误，立即停止传输正文。  
    149 可能 (MAY) 8.2.2 使用“chunked”编码发送消息正文时，如果检测到网络错误，立即停止传输正文，并用零长度块和空 trailer 标记终止  
    150 必须 (MUST) 8.2.2 在发送带有 content-length 报头的内容正文时，如果检测到网络错误，立即停止传输正文并关闭连接  
    151 必须 (MUST) 8.2.3 对于客户端程序 - 如果等待 100 才能发送请求正文，请发送一个带有“100-continue”期望的 Expect 请求头  
    152 不得 (MUST NOT) 8.2.3 对于客户端程序 - 如果我们不打算发送请求正文，请发送一个带有“100-continue”期望的 Expect 请求头  
    153 不应该 (SHOULD NOT) 8.2.3 对于客户端程序 - 如果在发送请求正文之前等待 100，则不要无限期地等待，然后发送请求正文  
    154 必须 (MUST) 8.2.3 对于 squid ‘服务器’ - 当我们收到带有“100-continue”期望的 Expect 请求头时，响应状态 100 并继续从输入流读取，或响应最终状态码  
    155 不得 (MUST NOT) 8.2.3 对于 squid ‘服务器’ - 当我们收到带有“100-continue”期望的 Expect 请求头时，在发送 100 响应之前等待请求正文。  
    156 可能 (MAY) 8.2.3 对于 squid ‘服务器’ - 当我们收到带有“100-continue”期望的 Expect 请求头并发送最终状态码时，关闭传输连接  
    157 可能 (MAY) 8.2.3 对于 squid ‘服务器’ - 当我们收到带有“100-continue”期望的 Expect 请求头并发送最终状态码时，完成读取请求（并丢弃它）  
    158 不得 (MUST NOT) 8.2.3 对于 squid ‘服务器’ - 当我们收到带有“100-continue”期望的 Expect 请求头并发送最终状态码时，完成读取请求并执行请求的方法  
    159 不应该 (SHOULD NOT) 8.2.3 对于 squid ‘服务器’ - 如果请求头不包含带有 100-continue 期望的 Expect 请求头，则发送 100 continue 状态  
    160 不得 (MUST NOT) 8.2.3 对于 squid ‘服务器’ - 如果请求来自 HTTP/1.1 之前的客户端，则发送 100 continue 状态。  
    161 可能 (MAY) 8.2.3 对于 squid ‘服务器’ - 响应 PUT 或 POST 请求（不包含 expect 100-continue 期望报头）时，发送 100 continue 状态  
    162 可能 (MAY) 8.2.3 对于 squid ‘服务器’ - 如果部分或全部请求正文已收到，则省略 100 continue 状态  
    163 必须 (MUST) 8.2.3 对于 squid ‘服务器’ - 在处理完请求后，发送最终状态码（一个或多个 100 状态码之后），除非传输连接过早终止  
    164 不应该 (SHOULD NOT) 8.2.3 对于 squid ‘服务器’ - 关闭正在接收请求正文的传输连接，直到整个请求读取完毕或客户端关闭连接，即使我们已经发送了最终状态码  
    165 必须 (MUST) 8.2.3 当收到带有 100-continue 期望的 Expect 报头时，并且下一跳服务器是 HTTP/1.1 或更高版本，或版本未知，则转发请求，包括 Expect 报头字段  
    166 不得 (MUST NOT) 8.2.3 当收到带有 100-continue 期望的 Expect 报头时，并且下一跳服务器是 HTTP/1.0 或更低版本，则转发请求  
    167 必须 (MUST) 8.2.3 当收到带有 100-continue 期望的 Expect 报头时，并且下一跳服务器是 HTTP/1.0 或更低版本，则响应 417 状态  
    168 应该 (SHOULD) 8.2.3 缓存最近访问的下一跳服务器的 http 版本  
    169 不得 (MUST NOT) 8.2.3 如果请求来自 HTTP/1.0 或更早的客户端，并且不包含带有 100 continue 期望的 expect 报头字段，则转发 100 响应  
    170 应该 (SHOULD) 8.2.4 当连接在收到任何服务器状态之前关闭，并且存在请求正文，并且请求不带 100-continue 期望的 Expect 字段，并且我们“不直接连接到 HTTP/1.1 源服务器”时，重试发送的请求 我不知道“直接..真正意味着”什么
    171 可能 (MAY) 8.2.4 当连接在收到任何服务器状态之前关闭，并且存在请求正文，并且请求不带 100-continue 期望的 Expect 字段，并且我们“不直接连接到 HTTP/1.1 源服务器”时，“重试发送的请求”采用二进制指数退避算法  
    172 不应该 (SHOULD NOT) 8.2.4 当收到错误状态时，按照 rfc 8.2.4 继续重试请求  
    173 应该 (SHOULD) 8.2.4 在（按照 rfc 8.2.4 重试请求时收到错误状态）请求未完成发送时，关闭连接  
    174 必须 (MUST) 9 将 Host 请求报头字段与 ALL HTTP/1.1 请求一起发送  
    175 不应该 (SHOULD NOT) 9.1.1 除检索外，使用 GET 和 HEAD 方法（squid 无副作用）  
    176 不应该 (SHOULD NOT) 9.1.2 接收到以 OPTIONS 或 TRACE 作为方法的 squid 请求时产生副作用  
    177 不得 (MUST NOT) 9.2 缓存 OPTIONS 请求的结果  
    178 必须 (MUST) 9.2 对于客户端程序 - 在发送带有实体正文的 OPTIONS 请求时，包含 content type 字段  
    179 可能 (MAY) 9.2 对于 squid ‘服务器’ - 丢弃 OPTIONS 请求的请求正文  
    180 应该 (SHOULD) 9.2 对 OPTIONS 方法的 200 响应应包含指示服务器实现的可选功能并适用于该资源的任何报头字段（例如 Allow）  
    181 应该 (SHOULD) 9.2 对带有消息正文的 OPTIONS 方法的 200 响应应包含有关通信选项的信息  
    182 可能 (MAY) 9.2 使用内容协商来选择 OPTIONS 方法的 200 响应中消息正文信息格式  
    183 必须 (MUST) 9.2 对 OPTIONS 方法的 200 响应，包含值为 0 的 Content-length 报头或响应正文  
    184 可能 (MAY) 9.2 对于客户端程序 - 使用 Max-Forwards 请求报头将请求链中的特定代理作为目标。  
    185 必须 (MUST) 9.2 当 squid 收到允许请求转发的 absoluteURI 上的 OPTIONS 请求时，检查 Max-Forwards 字段  
    186 不得 (MUST NOT) 9.2 当 squid 收到允许请求转发的 absoluteURI 上的 OPTIONS 请求，且 Max-Forwards 的值为 0 时，转发带有 Max-Forwards 字段的请求。  
    187 应该 (SHOULD) 9.2 当 squid 收到允许请求转发的 absoluteURI 上的 OPTIONS 请求，且 Max-Forwards 的值为 0 时，响应 Squid 的通信选项。  
    188 必须 (MUST) 9.2 当 squid 收到允许请求转发的 absoluteURI 上的 OPTIONS 请求，且 Max-Forwards 的值为非零整数时，递减 Max-Forwards 字段值并转发。  
    189 不得 (MUST NOT) 9.2 当 squid 收到 OPTIONS 请求时，如果不存在 Max-Forwards 报头，则添加一个 Max-Forwards 报头  
    190 不得 (MUST NOT) 9.3 如果 GET 响应不符合 rfc 2616 第 13 节的 HTTP 缓存要求，则缓存该响应  
    191 不得 (MUST NOT) 9.4 对于 squid ‘服务器’ - 在 HEAD 响应中生成消息正文  
    192 应该 (SHOULD) 9.4 对于 squid ‘服务器’ - 为 HEAD 请求生成与等效 GET 请求相同的 http 报头。  
    193 可能 (MAY) 9.4 使用 HEAD 请求响应的报头更新先前缓存的实体  
    194 必须 (MUST) 9.4 将 HEAD 请求响应指示实体已更改（通过 Content-Length、Content-MD5、Etag 或 Last-Modified 的更改指示）的缓存实体标记为 stale  
    195 必须 (MUST) 9.5 遵循 POST 请求的第 8.2 节消息传输要求  
    196 不得 (MUST NOT) 9.5 除非 POST 响应包含适当的 cache-control 或 Expires 报头，否则缓存 POST 响应  
    197 应该 (SHOULD) 9.6 对于 squid ‘服务器’ - 处理 PUT 请求 - 我跳过了这些，因为 cachmgr 接口没有文件存储能力  
    198 应该 (SHOULD) 9.6 将匹配 PUT 请求的 Request URI 的任何已缓存实体视为 stale  
    199 必须 (MUST) 9.6 遵循 PUT 请求的第 8.2 节消息传输要求  
    200 不得 (MUST NOT) 9.6 缓存对 PUT 方法请求的响应  
    201 应该 (SHOULD) 9.7 对于 squid ‘服务器’ - 处理 DELETE 请求 - 我跳过了这些，因为 cachmgr 接口没有文件存储能力 也许我们可以使用 DELETE squid-server/http///originaluri 来通过 Web 删除缓存的实体？
    202 应该 (SHOULD) 9.7 将匹配 DELETE 请求的 Request URI 的任何已缓存实体视为 stale  
    203 不得 (MUST NOT) 9.7 缓存对 DELETE 方法请求的响应  
    204 不得 (MUST NOT) 9.8 对于 squid 客户端 - 创建带有实体的 TRACE 请求  
    205 应该 (SHOULD) 9.8 当 Max-forwards 值为 0 时，将收到的 TRACE 消息反射回客户端，作为 200 响应的实体正文。实体正文的内容类型应为 message/http  
    206 不得 (MUST NOT) 9.8 缓存对 TRACE 方法请求的响应  
    207 不得 (MUST NOT) 10.1 对于 squid ‘服务器’ - 向 < HTTP/1.1 客户端发送 1xx 响应代码  
    208 必须 (MUST) 10.1 对于客户端 - 准备好接受一个或多个 1xx 状态响应，然后是常规响应，即使客户端不期望 100 状态消息  
    209 必须 (MUST) 10.1 转发 1xx 响应，除非 squid-client 连接已关闭，或者 squid 请求了 1xx 响应的生成。（即，squid 添加了 expect: 100-continue，那么 squid 不需要转发 100 响应  
    210 应该 (SHOULD) 10.1.1 对于客户端，在收到 100-continue 响应时，应继续处理请求，或在请求完成后忽略。  
    211 必须 (MUST) 10.1.1 对于 squid ‘服务器’ - 在处理完请求后发送最终响应  
    212 应该 (SHOULD) 10.1.2 仅在有利可图时才升级协议。  
    213 必须 (MUST) 10.2.2 对于 squid ‘服务器’ - 处理 PUT 请求 - 我跳过了这些，因为 cachmgr 接口没有文件存储能力  
    214 必须 (MUST) 10.2.5 通过报头字段后的第一个空行终止 204 响应  
    215 不得 (MUST NOT) 10.2.6 在 205 响应中包含实体  
    216 不得 (MUST NOT) 10.2.7 将 206 响应与相同实体的旧内容合并，除非 Etag 或 Last-Modified 报头完全匹配  
    217 不得 (MUST NOT) 10.2.7 除非我们支持 Range 和 Content-Range 报头，否则缓存 206 响应  
    218 必须 (MUST) 10.2.7 在 206 响应下游包含以下报头 - Content-Range 或 multipart/byteranges content-type，每个部分都有 content-range；Date；Etag 和/或 Content-Location；Expires/cache0control 和/或 vary（如果字段值可能与之前对同一变体的请求不同）；  
    219 必须 (MUST) 10.2.7 对带有 if-range & 强验证器的请求的 206 响应 - 不应有其他实体报头；if-range 和弱验证器 - 绝不能有其他实体报头；否则，应包含 200 响应会给到相同请求的所有实体报头  
    220 应该 (SHOULD) 10.3.2 除非另有说明，否则缓存 301 响应  
    221 不得 (MUST NOT) 10.3.2 缓存除 GET 或 HEAD 请求以外的 301 响应  
    222 不得 (MUST NOT) 10.3.3 除非 Cache-Control 或 Expires 报头另有指示，否则缓存 302 响应  
    223 不得 (MUST NOT) 10.3.3 缓存除 GET 或 HEAD 请求以外的 302 响应  
    224 不得 (MUST NOT) 10.3.4 缓存 303 响应  
    225 必须 (MUST) 10.3.5 对于 squid ‘服务器’ - 在 304 响应中包含 Date（除非 rfc 2616 第 14.18.1 节要求省略）；Etag 和/或 Content-Location（如果同一请求的 200 响应有这些字段）；Expires、Cache-Control 和/或 Vary（如果字段值可能与之前请求的不同）  
    226 必须 (MUST) 10.3.5 当 304 响应指示一个当前未缓存的实体时，忽略该响应并无条件地重新发送请求  
    227 必须 (MUST) 10.3.5 当接收到当前已缓存实体的 304 响应时，使用响应中提供的新字段值更新条目  
    228 必须 (MUST) 10.3.6 当收到 305 响应时，通过 ‘Location’ 中的代理重复该 *单次* 请求 这是 squid 应该做的，还是只为客户端做的？防火墙后面的只能使用 squid 的客户端怎么办？
    229 不得 (MUST NOT) 10.3.6 生成 305 响应，但不是来自 squid ‘服务器’  
    230 不得 (MUST NOT) 10.3.7 使用 306 状态码  
    231 不应该 (SHOULD NOT) 10.4.1 重试返回 400 的请求，除非是客户端重试  
    232 不应该 (SHOULD NOT) 10.4.4 重试返回 403 的请求  
    233 必须 (MUST) 10.4.6 当 squid 向客户端创建 405 方法时，包含列出有效方法的 Allow 报头  
    234 必须 (MUST) 10.4.8 返回一个 Proxy-Authenticate 报头，其中包含适用于 squid 的挑战，用于请求的资源。  
    235 可能 (MAY) 10.4.9 重试 408 请求  
    236 不应该 (SHOULD NOT) 10.4.10 自动重试 409 响应  
    237 应该 (SHOULD) 10.4.11 缓存 410 响应 我们应该清除接收到 410 响应的已缓存实体正文。
    238 可能 (MAY) 10.4.12 在响应 411 错误时，自动重试带有 Content-Length 报头的请求 未知 (unknown)
    239 可能 (MAY) 10.4.12 如果想轻松过滤 put 和 post 请求而客户端没有使用 Content-Length 报头，则向客户端返回 411 错误  
    240 可能 (MAY) 10.4.14 当请求实体过大时返回 413 错误。  
    241 应该 (SHOULD) 10.4.14 当请求实体过大且是基于时间的（或临时的）限制而返回 413 错误时，请包含一个 Retry-After 报头，指示何时可以重试。  
    242 应该 (SHOULD) 10.4.18 当我们有确凿证据表明下一跳服务器无法满足请求中给出的期望时，返回 417。  
:rage: :rage: 243 应该 (SHOULD) 10.5 当我们创建 5xx 错误响应时，包含一个实体正文来解释问题（除了对 HEAD 请求）。  
    244 应该 (SHOULD) 10.5.2 如果我们不实现给定的方法，并且无法将其代理出去并寄希望于它，则返回 501。  
    245 应该 (SHOULD) 10.5.3 如果我们收到无效的上游响应，则返回 502。  
    246 应该 (SHOULD) 10.5.4 如果我们过载，或因维护而无法响应请求，则返回 503。  
    247 可能 (MAY) 10.5.4 当我们过载或因维护而无法响应请求而返回 503 时，返回 Retry-After。（报头将指示维护何时完成。  
    248 应该 (SHOULD) 10.5.5 当上游超时，或辅助服务器（例如 DNS/身份验证助手）超时时，返回 504。 我们目前可能返回 400 或 500。
:frowning: :rage: 3.1 249 必须 (MUST) 10.5.6 如果我们不支持（或已禁用）请求消息中的 HTTP 主版本，则返回 505。  
:rage: :rage: 250 可选 (OPTIONAL) 11 实现基本和/或摘要身份验证。  
:frowning: :rage: 251 可能 (MAY) 12 在任何实体正文请求/响应中使用内容协商，例如在选择错误的语言时。  
    252 可能 (MAY) 12.1 对于 squid 客户端，在请求中包含请求报头字段（Accept, Accept-Language, Accept-Encoding 等）。  
    253 可能 (MAY) 12.3 在 HTTP/1.1 中开发透明协商功能。  
    254 建议 (recommendation) 13 注意：服务器、缓存或客户端实现者可能会面临本规范未明确讨论的设计决策。如果一个决定可能影响语义透明度，实现者应该倾向于保持透明度，除非经过仔细和完整的分析表明打破透明度有显著的好处。  
    255 必须 (MUST) 13.1.1 以 squid 持有的最最新的、适合请求的响应来响应请求（参见 13.2.5,13.2.6,13.12），并且满足以下条件之一：1) 已与源进行重新验证，2) 它“足够新鲜”（参见 13.12）& 14.9 或 3) 它是合适的 304/305/4xx/5xx 响应。  
2.7   256 可能 (MAY) 13.1.1 如果存储的响应根据客户端和源服务器的最严格的 freshness 要求都不“足够新鲜”，在经过仔细考虑的情况下，缓存 MAY 仍返回带有适当 Warning 报头的响应（参见第 13.1.5 和 14.46 节），除非此类响应被禁止（例如，被“no-store”缓存指令，或被“no-cache”缓存请求指令；参见第 14.9 节）。  
    257 应该 (SHOULD) 13.1.1 即使响应本身已过时，也要转发收到的响应，而不添加新的 Warning 报头。  
    258 不应该 (SHOULD NOT) 13.1.1 尝试重新验证在传输到 squid 过程中过时的响应。  
    259 应该 (SHOULD) 13.1.1 即使无法联系到源服务器，也按照 13.1.1 的响应规则进行响应。  
    260 必须 (MUST) 13.1.1 如果无法联系到源服务器，并且在 13.1.1 规则下无法提供任何响应，则向客户端返回错误或警告。  
    261 必须 (MUST) 13.1.2 当返回一个既不是一手也不是“足够新鲜”的响应时，使用 Warning 报头附加一个警告。  
    262 必须 (MUST) 13.1.2 在成功重新验证后，从缓存的响应中删除 1xx 警告。  
    263 可能 (MAY) 13.1.2 在验证缓存条目时生成 1xx 警告。  
    264 不得 (MUST NOT) 13.1.2 在成功重新验证后，从缓存的响应中删除 2xx 警告。  
    265 可能 (MAY) 13.1.2 选择警告文本描述的语言（可能基于 Accept 报头）。  
    266 可能 (MAY) 13.1.2 允许/创建带有多个警告的响应，包括带有相同代码的多个警告。  
    267 建议 (recommendation) 13.1.3 对缓存问题/规范冲突进行最严格的解释。  
:rage: :rage: 268 可能 (MAY) 13.1.5 使 squid 可配置以返回过时的响应，即使客户端未请求。  
    269 必须 (MUST) 13.1.5 用 Warning 报头标记过时的响应。  
    270 不应该 (SHOULD NOT) 13.1.5 当客户端明确请求一手或新鲜响应时，返回过时响应，除非技术或策略原因要求返回过时响应。 例如：离线模式，刷新到 IMS 被允许，但必须需要管理员的明确配置。
不适用 不适用 271 应该 (SHOULD) 13.2.3 在运行 NTP 或等效的时钟同步功能的宿主上运行。  
    272 必须 (MUST) 13.2.3 计算 corrected_received_age 为 max(now-date_value, age_value)。  
    273 必须 (MUST) 13.2.3 将 Age 报头值（age_value）解释为相对于请求发起的时间，而不是响应时间。  
    274 必须 (MUST) 13.2.3 计算 corrected_initial_age 为 corrected_received_age +(now - request_time)；request_time = 发送请求到上游的时间。  
    275 必须 (MUST) 13.2.3 当发送来自缓存条目的响应时，包含一个 Age 报头，其值为 current_age（根据 13.2.3 算法）。  
    276 可能 (MAY) 13.2.4 当响应没有缓存限制且响应中没有 Expires、Cache-Control: Max-age、Cache-Control: s-maxage 时，使用启发式计算 freshness lifetime。  
    277 必须 (MUST) 13.2.4 当 age_value 大于 24 小时且没有 113 警告时，向任何响应附加警告 113。  
    278 应该 (SHOULD) 13.2.4 使用启发式方法，该方法使用最后修改时间（如果存在）的一部分，建议设置为 last-modified 以后的 10%。  
    279 必须 (MUST) 13.2.5 当给定表示存在两个具有不同验证器的响应时，使用具有更近 Date 报头的那个。 例如，不要天真地假设传入的响应比它正在刷新的实体新。
    280 应该 (SHOULD) 13.2.6 当发生重新验证且响应的日期报头比现有条目旧时，无条件地重复请求，带有 Cache-Control: max-age=0 或 Cache-Control: no-cache 报头。 请注意，这被规定为客户端的要求 - 但我们也必须实现客户端代码。Squid 需要这样做还是让客户端去做？？
    281 不得 (MUST NOT) 13.3.3 在除简单（非子范围）GET 请求之外的任何请求中使用弱验证器。  
    282 必须 (MUST) 13.3.3 当两个验证器相同，并且两者都不是弱验证器时，认为这两个验证器强相等。  
    283 必须 (MUST) 13.3.3 当两个验证器相同，并且其中一个或两个不是强验证器时，认为这两个验证器弱相等。  
    284 必须 (MUST) 13.3.3 除非我们将 Last-Modified 与缓存的 last-modified 日期进行比较，并且缓存条目包含 Date 值，并且 last-modified 比数据值早至少 60 秒，否则 Last-Modified 被视为弱验证器。  
    285 必须 (MUST) 13.3.3 在收到条件请求时，使用强比较（不允许弱比较）。  
    286 不得 (MUST NOT) 13.3.4 当条件请求同时包含 last-modified（例如在 IMS 或 IUS 报头中）和至少一个实体标签（例如 If-match / IF-None-Match/If-Range）时，返回 304 给该请求，除非 304 与请求中存在的所有条件都一致。  
    287 不得 (MUST NOT) 13.3.4 当条件请求同时包含 Last-Modified 和至少一个实体标签作为验证器时，向客户端返回本地缓存的响应，除非缓存的响应与请求中存在的所有条件都一致。  
    288 不得 (MUST NOT) 13.3.5 使用实体标签和 Last-Modified 以外的其他报头进行验证。  
    289 可能 (MAY) 13.4 始终缓存成功响应（除非受 14.9 约束）。  
    290 可能 (MAY) 13.4 在新鲜期间返回缓存的响应而不进行验证（除非受 14.9 约束）。  
    291 可能 (MAY) 13.4 成功验证后返回缓存的响应（除非受 14.9 约束）。  
    292 可能 (MAY) 13.4 缓存没有验证器或过期时间的响应，但在正常情况下不应这样做。  
    293 可能 (MAY) 13.4 缓存并作为回复使用状态码为 200、203、206、300、301 或 410 的响应（受过期和缓存控制机制的约束）。  
    294 不得 (MUST NOT) 13.4 向后续请求返回除（200、203、206、300、301 或 410）以外的状态码的响应，除非有缓存控制指令明确允许（例如 Expires/ a max-age, s-maxage, must-revalidate, proxy-revalidate, puvlic 或 private cache-control header）。  
    295 必须 (MUST) 13.5.1 将端到端报头（除 Connection; Keep-Alive ; Proxy-Authenticate ; Proxy-Authorization ; TE ; Trailers ; Transfer-Encoding ; Upgrade 之外的报头）与缓存的响应一起存储。  
    296 必须 (MUST) 13.5.1 在由该缓存条目形成的任何响应中传输缓存的端到端报头。  
    297 必须 (MUST) 13.5.1 在 Connection 报头下列出新定义的 hop-to-hop 报头。  
    298 不应该 (SHOULD NOT) 13.5.2 修改端到端报头，除非该报头的定义明确允许或要求其修改。  
    299 不得 (MUST NOT) 13.5.2 作为透明代理，修改请求或响应中的（Content-Location; Content-MD5;- Etag; Last-Modified; Expires）报头。  
    300 可能 (MAY) 13.5.2 作为透明代理，如果响应中没有 Expires 报头，则添加一个，并且必须给它与该响应的 Date 报头相同的值。  
    301 不得 (MUST NOT) 13.5.2 作为透明代理，在请求或响应中添加（Content-Location; Content-MD5;- Etag; Last-Modified）报头。  
    302 可能 (MAY) 13.5.2 作为非透明代理，在不包含“no-transform”的请求或响应中修改或添加（Content-Location; Content-MD5;- Etag; Last-Modified; Expires）报头。  
    303 必须 (MUST) 13.5.2 作为非透明代理，如果我们选择修改或添加（Content-Location; Content-MD5;- Etag; Last-Modified; Expires）报头到不包含“no-transform”的请求或响应中，则添加警告 214（如果尚未存在）。  
    304 必须 (MUST) 13.5.2 作为透明代理，在响应/请求中保留实体正文的实体长度。  
    305 可能 (MAY) 13.5.2 作为透明代理，更改响应/请求中的传输长度。  
    306 可能 (MAY) 13.5.3 只要 Etag 或 Last-Modified 报头完全匹配，就将 206 响应与相同实体的缓存内容合并。  
    307 必须 (MUST) 13.5.3 当合并 206 响应与缓存内容时，删除 1xx 警告报头，保留 2xx 警告报头，并优先使用 206 响应的端到端报头而不是缓存的报头。  
    308 必须 (MUST) 13.5.3 当合并 206 响应与缓存内容时，删除 1xx 警告报头，保留 2xx 警告报头，并优先使用 206 响应的端到端报头而不是缓存的报头。  
    309 可能 (MAY) 13.5.4 如果传入响应和缓存条目都有验证器，并且验证器使用强比较匹配，则合并字节范围。  
    310 必须 (MUST) 13.5.4 如果收到子范围响应，并且传入响应或缓存条目没有验证器，或者验证器不匹配，则仅使用最新的（检查 Date 报头，否则检查传入响应）部分响应，并丢弃先前部分的信息。  
    311 不得 (MUST NOT) 13.5.6 使用缓存条目来构建对具有 Vary 报头的请求的响应，除非 Vary 字段列出的所有请求报头都与相应的缓存请求报头匹配（通过根据 BNF 插入 LWS 或根据 4.2 合并同名消息报头来匹配）。  
    312 不得 (MUST NOT) 13.5.6 使用缓存条目来构建对具有 Vary 报头为 * 的请求的响应，而不进行源服务器验证。  
    313 应该 (SHOULD) 13.5.6 如果为缓存的表示分配了实体标签，则转发的请求应为条件请求，并在 If-None-Match 报头字段中包含来自该资源所有缓存条目的实体标签。  
    314 不应该 (SHOULD NOT) 13.5.6 在 If-None-Match 报头中包含仅包含部分内容的缓存条目的实体标签，除非请求可以从缓存中满足。  
    315 应该 (SHOULD) 13.5.6 当收到具有匹配 Content-Location 字段、不同实体标签和更近 Date 的成功响应时，删除缓存条目。  
    316 不应该 (SHOULD NOT) 13.5.6 当收到具有匹配 Content-Location 字段、不同实体标签和更近 Date 的成功响应时，使用缓存条目来满足请求。  
    317 可能 (MAY) 13.8 存储不完整的响应。  
    318 必须 (MUST) 13.8 将不完整的响应视为部分响应。  
    319 不得 (MUST NOT) 13.8 向客户端返回部分响应，而不将其标记为部分响应（使用 206 状态码）。  
    320 不得 (MUST NOT) 13.8 使用状态码 200 向客户端返回部分响应。  
    321 可能 (MAY) 13.8 在重新验证条目时收到的 5xx 响应转发给客户端，或视为服务器未能响应。  
    322 可能 (MAY) 13.8 当服务器未能响应时，返回缓存的响应，除非缓存条目包含 must-revalidate 缓存控制指令。  
    323 不得 (MUST NOT) 13.9 将带有 ? 的 URI 路径的 GET 和 HEAD 请求视为新鲜的，除非响应中提供了明确的过期时间。  
    324 不应该 (SHOULD NOT) 13.9 缓存来自带有 ? 的 URI 路径的 HTTP/1.0 服务器的 GET 和 HEAD 响应。  
    325 必须 (MUST) 13.10 在 PUT/DELETE 和 POST 请求中，使 Content-Location 报头；Location 报头或 Request-URI 引用的实体失效。仅对同一主机使用 Content-Locaiton 和 Location 报头进行此操作。  
    326 应该 (SHOULD) 13.10 在不被理解的方法中，使 Request-URI 引用的实体失效，如果我们将其转发到上游。  
    327 必须 (MUST) 13.11 将可能导致源服务器资源发生变化的所有方法（除了 GET 和 HEAD）转发到上游。  
    328 不得 (MUST NOT) 13.11 在服务器响应到达之前，对可能导致源服务器资源发生变化的所有方法（除了 GET 和 HEAD）向客户端进行响应。  
    329 可能 (MAY) 13.11 在服务器响应到达之前，对可能导致源服务器资源发生变化的所有方法（除了 GET 和 HEAD）向客户端响应 100。  
    330 应该 (SHOULD) 13.12 当新响应到达现有缓存资源时，使用新响应来回复当前请求。  
    331 可能 (MAY) 13.12 当新响应到达现有缓存资源时，使用新响应更新缓存。  
    332 可能 (MAY) 13.12 当新响应到达现有缓存资源时，使用它来响应未来的请求，视情况而定。  
    333 可能 (MAY) 14.1 包含支持它们的媒体类型的参数。  
    334 可能 (MAY) 14.1 为媒体类型包含 accept-params (q=0 到 q=1) (参见 3.9)。  
    335 应该 (SHOULD) 14.1 对于 squid ‘server’，如果我们无法为客户端请求获取可接受的媒体类型，则发送 406。  
    336 可能 (MAY) 14.2 为字符集提供 q 值。  
    337 应该 (SHOULD) 14.2 对于 squid ‘server’，如果我们无法为客户端请求获取可接受的字符集，则发送 406。  
    338 可能 (MAY) 14.3 为内容编码提供 q 值。  
    339 应该 (SHOULD) 14.3 对于 squid ‘server’，如果我们无法为客户端请求获取可接受的内容编码，则发送 406。注意，这不是传输编码，所以我们无法在缓存上动态完成此操作。  
    340 可能 (MAY) 14.3 当没有提供 Accept-Encoding 报头时，假设客户端将接受任何内容编码。  
    341 应该 (SHOULD) 14.3 对于 squid ‘server’，当没有提供 Accept-Encoding 报头时，发送 identity 内容编码。  
不适用 不适用 342 可能 (MAY) 14.4 为首选语言提供 q 值。  
:rage: :rage: 343 应该 (SHOULD) 14.4 当没有报头时，假设所有语言都可以。  
    344 可能 (MAY) 14.5 对于 squid ‘server’，发送 Accept-ranges: none，以告知客户端不要尝试范围请求。  
    345 必须 (MUST) 14.6 当收到的 Age 报头大于我们最大的整数，或者 Age 计算溢出时，传输 Age 2147483648 (2^31)。  
    346 应该 (SHOULD) 14.6 使用至少 31 位的整数。  
    347 必须 (MUST) 14.7 在 405 响应中呈现 Allow 报头。  
    348 不得 (MUST NOT) 14.7 修改 Allow 报头。  
    349 应该 (SHOULD) 14.8 拥有一套对整个域（包括所有子资源）有效的凭据（即用于 web-accel 操作）。  
    350 不得 (MUST NOT) 14.8 除非 a) 存在 cache-control: s-maxage 或 b) 存在 cache-control: must-revalidate 或 c) 存在 cache-control: public，否则向其他请求返回带有 Authorization 报头的响应。  
    351 必须 (MUST) 14.8 始终重新验证带有 cache-control: s-maxage=0 的响应。  
    352 必须 (MUST) 14.9 始终遵循 cache-control 报头指令。  
    353 必须 (MUST) 14.9 将 cache-control 指令传递给消息路径的下一环节（即不要丢弃它们）。  
    354 可能 (MAY) 14.9.1 缓存带有 cache-control: public 的响应，即使该报头/方法通常不可缓存。  
    355 不得 (MUST NOT) 14.9.1 缓存带有 cache-control: private 的响应。  
    356 不得 (MUST NOT) 14.9.1 使用带有 cache-control: no-cache 的响应来满足其他请求，而无需成功重新验证。 例如，允许自动 GET 到 IMS。
    357 可能 (MAY) 14.9.1 使用带有 cache-control: no-cache 的响应来满足其他请求，而无需成功重新验证，如果 no-cache 指令包含字段名。  
    358 不得 (MUST NOT) 14.9.1 在带有 cache-control: no-cache（header…）的响应中发送列出的报头，以满足其他请求，而无需成功重新验证，如果 no-cache 指令包含字段名。  
    359 可能 (MAY) 14.9.2 使用 no-store 在请求或响应上来阻止数据存储。  
    360 不得 (MUST NOT) 14.9.2 如果请求中存在 cache-control: no-store 指令，则存储请求的任何部分或其响应。 此指令适用于非共享和共享缓存。“MUST NOT store”在此上下文中意味着缓存 MUST NOT 故意将信息存储在非易失性存储器中，并且在转发信息后 MUST 尽最大努力尽快将其从易失性存储器中删除。
    361 不得 (MUST NOT) 14.9.2 如果响应中存在 cache-control: no-store 指令，则存储响应的任何部分或引起它的请求。 此指令适用于非共享和共享缓存。“MUST NOT store”在此上下文中意味着缓存 MUST NOT 故意将信息存储在非易失性存储器中，并且在转发信息后 MUST 尽最大努力尽快将其从易失性存储器中删除。
    362 应该 (SHOULD) 14.9.3 将 Expires 值小于等于响应日期的且没有 cache-control 报头字段的响应视为不可缓存。  
    363 必须 (MUST) 14.9.3 用 Warning 110 标记过时的响应。  
    364 可能 (MAY) 14.9.3 使 squid 可配置以返回过时的响应，即使客户端未请求，但提供的响应不能与其他 MUST 或 MUST NOT 要求冲突。  
    365 不得 (MUST NOT) 14.9.4 使用缓存的副本响应带有 cache-control: no-cache 或 Pragma: no-cache 的请求。  
    366 应该 (SHOULD) 14.9.4 响应带有缓存的副本（如果可能）或 504 给带有 cache-control: only if cached 的请求。请注意，我们可以使用缓存农场来获取缓存的副本。  
    367 不得 (MUST NOT) 14.9.4 在变为过时后，使用带有 cache-control: must-revalidate 标记的过时响应，而不先与源进行重新验证。  
    368 必须 (MUST) 14.9.4 始终遵守 must-revalidate 指令。  
    369 必须 (MUST) 14.9.4 如果 must-revalidate 指令需要访问不可用的源服务器，则返回 504。  
    370 不得 (MUST NOT) 14.9.5 当收到带有 cache-control: no-transform 的消息时，更改第 13.5.2 节中指定的任何报头（或报头指定的请求部分）。  
    371 必须 (MUST) 14.9.6 忽略无法识别的 cache-control 报头。  
  :rage: 372 必须 (MUST) 14.10 在转发消息之前解析 Connection 报头。  
  :rage: 373 必须 (MUST) 14.10 从与 Connection 报头中指定的报头匹配的消息中删除报头。  
  :rage: 374 不得 (MUST NOT) 14.10 在 Connection 报头中列出端到端报头。  
    375 必须 (MUST) 14.10 对于不支持持久连接的应用程序（例如 squid ‘server’ 和 client），在每条消息中包含 Connection: close。  
  :rage: 376 必须 (MUST) 14.10 对于带有 connection 报头的 pre-http/1.1 消息，对于每个 connection-token，删除并忽略与 token 同名的任何报头字段。  
  :rage: 377 可能 (MAY) 14.11 作为非透明代理，修改内容编码以使其更适合客户端请求。  
    378 必须 (MUST) 14.11 如果实体的内容编码不是“identity”。  
    379 必须 (MUST) 14.11 按应用顺序列出应用于实体的所有内容编码。  
不适用 不适用 380 可能 (MAY) 14.12 如果在响应中包含多个语言，则在 Content-Language 报头中列出多种语言（也许是多语言错误页面？）。 仅发送一种语言。
    381 应该 (SHOULD) 14.13 使用并发送 Content-Length 报头，除非受第 4.4 节禁止。  
    382 不得 (MUST NOT) 14.15 生成 Content-MD5 报头。  
    383 可能 (MAY) 14.15 检查 Content-MD5 报头。  
    384 必须 (MUST) 14.15 在检查 MD5 之前删除传输编码。  
    385 不得 (MUST NOT) 14.15 在检查 MD5 之前将换行符转换为 CRLF。  
    386 应该 (SHOULD) 14.16 在 Content-Range 报头中指示完整实体正文的总长度。  
    387 必须 (MUST) 14.16 只在 byte-range-resp-spec 中指定一个范围。  
    388 必须 (MUST) 14.16 使用绝对字节位置作为 byte-range-resp-spec 的值。  
    389 必须 (MUST) 14.16 忽略无效的 byte-range-resp-spec 以及随之传输的任何内容。  
    390 不得 (MUST NOT) 14.16 使用响应代码 206 和 * 的 byte-range-resp-spec。  
    391 必须 (MUST) 14.18 如果我们收到没有 Date 报头的消息，则分配一个 Date 报头。  
    392 应该 (SHOULD) 14.18 当我们分配 Date 报头时，分配消息生成日期和时间的最佳可用近似值。  
    393 可能 (MAY) 14.19 使用实体标签与同一资源的其他实体进行比较。  
    394 必须 (MUST) 14.21 将无效的 Expires 报头（非 RFC 1123 格式）视为已过时。  
    395 可能 (MAY) 14.22 记录 From 报头。  
    396 不应该 (SHOULD NOT) 14.22 使用 From 报头进行访问控制。  
    397 必须 (MUST) 14.23 对于客户端，在所有 http/1.1 请求中包含 Host 报头。  
    398 必须 (MUST) 14.23 对于客户端，在所有 http/1.1 请求中，当没有可用的主机名时，包含一个空的 Host 报头。  
    399 必须 (MUST) 14.23 确保所有转发的请求都包含一个合适的 Host 报头。  
    400 必须 (MUST) 14.23 对于缺少 Host 报头的 http/1.1 请求，响应 400。  
    401 必须 (MUST) 14.24 在比较 If-Match 的实体标签时，使用强比较。  
    402 应该 (SHOULD) 14.25 对于未修改的 IMS 请求，返回 304（如果可能，使用缓存数据）。  
    403 必须 (MUST) 14.31 检查并（如果大于 0）递减 TRACE 和 OPTIONS 请求中存在的 Max-Forwards 报头。  
    404 必须 (MUST) 14.31 如果 TRACE 或 OPTIONS 请求的 Max-Forwards 报头为 0，则作为最终接收者响应。  
    405 可能 (MAY) 14.31 忽略 rfc 2616 涵盖的所有其他方法的 Max-Forwards 报头。  
    406 应该 (SHOULD) 14.32 即使存在缓存副本，也将带有 Pragme: no-cache 的请求转发到上游。  
    407 必须 (MUST) 14.32 在所有情况下，将 Pragma 指令向上/向下传递。  
    408 应该 (SHOULD) 14.32 忽略对我们而言不相关或不理解的 pragma 指令。  
    409 应该 (SHOULD) 14.32 将 pragme: no-cache 视为 cache-control: no-cache。  
    410 必须 (MUST) 14.33 在发送 407 响应时包含 Proxy-Authenticate。 注意：NTLM 认证需要一个不推荐的顺序。
    411 不应该 (SHOULD NOT) 14.33 将 Proxy-Authenticate 向下传递。  
    412 可能 (MAY) 14.34 将客户端的凭据中继给父缓存（如果这是两个缓存协同认证给定请求的机制）。  
    413 可能 (MAY) 14.35.1 在一个字节范围操作中，指定单个字节范围或单个实体内的范围集。  
    414 必须 (MUST) 14.35.1 当 last-byte-pos 值（如果存在）大于或等于 byte-range-spec 中的 first-byte-pos。  
    415 必须 (MUST) 14.35.1 忽略带有无效 byte-range-spec 的报头字段。  
    416 应该 (SHOULD) 14.35.1 如果 byte-range-set 无法满足，则返回 416。  
    417 应该 (SHOULD) 14.35.1 返回范围时返回 206。  
    418 可能 (MAY) 14.35.2 对于客户端，在有条件或无条件的 GET 请求中请求一个或多个子范围。  
    419 可能 (MAY) 14.35.2 忽略 Range 报头。 我们应该支持这一点，并且应该考虑缓存部分响应。
    420 应该 (SHOULD) 14.35.2 即使在响应包含范围请求的请求时收到整个实体，也只向客户端返回请求的范围。  
    421 应该 (SHOULD) 14.35.2 如果我们收到包含范围请求的请求的整个实体，则存储整个响应（如果我们通常会缓存该对象）。  
    422 不得 (MUST NOT) 14.36 对于客户端，如果 request-URI 不是从具有自身 URI 的源（例如键盘）获得的，则发送 referer 字段。  
    423 可能 (MAY) 14.37 使用 Retry-After 来指示客户端应等待多长时间才能请求新位置。  
    424 不得 (MUST NOT) 14.38 在转发响应时修改 Server 报头。  
  :rage: 425 应该 (SHOULD) 14.38 在转发响应时包含 Via 报头。 除非管理员禁用。
    426 必须 (MUST) 14.39 当我们使用 TE 连接时，包含 TE 连接令牌。  
    427 不应该 (SHOULD NOT) 14.40 在发送了 Trailer 报头后，在 trailer 中包含报头字段。  
    428 不得 (MUST NOT) 14.40 发送 Transfer-Encoding; Content-Length 或 Trailer 作为 Trailer 字段值。  
    429 必须 (MUST) 14.41 按应用顺序列出应用于响应的传输编码（例如 rsync, gzip。  
    430 必须 (MUST) 14.42 在状态码为 101 的响应中使用 upgrade 报头。  
    431 必须 (MUST) 14.42 当我们使用 Upgrade 报头时，包含 Upgrade 连接令牌。  
    432 应该 (SHOULD) 14.43 对于客户端，在请求中包含 User-Agent 字段。  
    433 应该 (SHOULD) 14.44 在任何我们生成的、使用了服务器协商的可缓存响应上包含 Vary 报头。  
    434 可能 (MAY) 14.44 对于“server”，在使用了服务器协商的不可缓存响应上包含 Vary 报头。  
    435 可能 (MAY) 14.44 在响应仍然新鲜期间，假设服务器对于具有与 Vary 报头中列出的值相同的请求字段值的未来请求将给出相同的响应。  
    436 不得 (MUST NOT) 14.44 为 vary 字段生成 * 值。  
    437 必须 (MUST) 14.45 填写 Via 报头。  
    438 可能 (MAY) 14.45 出于安全/隐私考虑，用假名替换 Via 报头中的主机。  
    439 必须 (MUST) 14.45 将我们的详细信息附加到 Via 报头。  
    440 可能 (MAY) 14.45 在转发之前，从 Via 报头中删除注释。  
    441 可能 (MAY) 14.45 在转发之前，在 Via 报头中添加注释。  
    442 不应该 (SHOULD NOT) 14.45 当用作网关/ http 防火墙时，转发防火墙内的宿主名称/主机/端口。 也许有一个配置指令 - firewall - 开启几个东西？
    443 应该 (SHOULD) 14.45 要求明确启用转发防火墙内的宿主名称/主机/端口。 也许有一个配置指令 - firewall - 开启几个东西？
    444 应该 (SHOULD) 14.45 当用作网关/ http 防火墙时，用假名替换收到的宿主，并转发防火墙内的宿主名称/主机/端口。  
    445 可能 (MAY) 14.45 对于有隐私顾虑的组织：将多个协议-值条目合并到 Via 报头中的一个条目。  
    446 不应该 (SHOULD NOT) 14.45 合并多个条目，除非它们都在同一组织控制之下，并且主机已经被假名化。  
    447 不得 (MUST NOT) 14.45 合并 Via 报头中具有不同协议值的多个条目。  
    448 可能 (MAY) 14.46 允许响应具有多个警告报头。  
    449 应该 (SHOULD) 14.46 以最可能让接收响应的用户理解的自然语言生成 warn-text。  
    450 可能 (MAY) 14.46 使用任何可用知识来决定警告的语言。  
    451 必须 (MUST) 14.46 如果以 ISO-8859-1 以外的字符集发送警告，则按照 rfc 2047 进行编码。  
    452 应该 (SHOULD) 14.46 在现有警告报头之后添加新的警告报头。  
    453 不得 (MUST NOT) 14.46 删除收到的带有给定消息的警告。  
    454 应该 (SHOULD) 14.46 在成功验证后，从缓存的响应中删除与缓存响应关联的任何警告报头（除某些警告代码的指定情况外）。  
    455 必须 (MUST) 14.46 将验证响应中收到的任何警告报头添加到缓存响应中。  
    456 必须 (MUST) 14.46 在过时的响应上生成警告 110。  
    457 必须 (MUST) 14.46 当重新验证失败而发送过时的响应时，生成警告 111。  
    458 应该 (SHOULD) 14.46 如果我们有意离线一段时间，则生成警告 112。  
    459 必须 (MUST) 14.46 如果我们的启发式选择的 freshness lifetime > 24 小时且响应的 age > 24 小时，则生成警告 113。  
    460 可能 (MAY) 14.46 在 Warning 199 中包含任何我们想要记录或呈现给用户的任意信息。  
    461 必须 (MUST) 14.46 如果我们更改了响应的内容编码或媒体类型，则生成警告 214（除非此警告已在响应中）。  
    462 可能 (MAY) 14.46 在 Warning 299 中包含任何我们想要记录或呈现给用户的任意信息。  
    463 必须 (MUST) 14.46 在具有警告报头的消息中，当版本是 HTTP/1.0 或更低时，包含一个与响应中的 Date 匹配的 warn-date。  
    464 必须 (MUST) 14.46 删除 warn-date 与响应中的 Date 值不同的 warning-values。  
    465 必须 (MUST) 14.46 如果警告报头为空，则删除它。  
:rage: :rage: 466 必须 (MUST) 14.47 在 401 响应中包含 WWW-Authenticate。  
    467 应该 (SHOULD) 15.1 小心不要泄露客户的个人信息。  
    468 应该 (SHOULD) 15.1.2 作为网关运行时，能够过滤/修改 From 字段。  
    469 应该 (SHOULD) 19.3 假设 RC 850 日期超过 50 年后的日期为过去。  
    470 可能 (MAY) 19.3 内部表示 Expires 日期比实际值早，但不得表示为比实际值晚。  
:rage: :rage: 471 必须 (MUST) 19.3 使用 GMT 进行日期计算。  
:rage: :rage: 472 必须 (MUST) 19.3 使用最保守的转换方式将 HTTP 报头日期转换为 GMT，如果它们不是 GMT。  
    473 想法 19.5.1 通过删除目录信息来清理 Content-Disposition 报头。  

类别：WantedFeature,Feature

导航：网站搜索，网站页面，分类，🔼 向上