问题标签 [rfc2616]

我有一个遗留产品，我试图在 Apache 服务器上支持，并且服务器仅在最近的更新开始拒绝仅将 LF 用于换行符的请求标头之后，并且由于代码库有多旧，重建它是一项艰巨的任务. 是否有可以使用的设置或可以利用 mod_rewrite 命令来允许使用 LF 而不是 CRLF 的请求标头，或者将 LF 重写为请求标头中的 CRLF？

来自应用程序的示例标头：

如果我对文件进行十六进制编辑以将其更改\n为\r\n，则它可以工作，但是不需要对文件进行十六进制编辑以作为更新发布，我正在尝试在服务器端找到一些东西来让 Apache 自己停止在 LF 上窒息。在此先感谢您对此问题的任何帮助！

我正在考虑启动一个辅助项目来了解如何构建 HTTP 服务器。

我开始搜索它，发现 RFC 文档中提到了规范。

但截至 2017 年 8 月，已有超过 8200 个 RFC。

进一步搜索它让我获得了用于 HTTP 的特定 RFC，即软件工程 stackexchange 上的RFC2616。有评论说“在 2014 年，RFC2616 被多个 RFC (7230-7237) 取代。 ”

那么，我们是否需要完全放弃 RFC2616 并阅读 RFC（7230-7237）？

我们可以在RFC2616上清楚地看到Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235.

那么，构建 HTTP 服务器的 RFC 是什么？我应该只阅读提到过时的文件吗？

我们最近从 Jetty v 6_1_26 切换到 9_4_11。

我们遵循以下网址：http: //jetty.4.x6.nabble.com/Configuring-option-2-of-RFC-7230-paragraph-5-HTTP-header-folding-td4966330.html

并在我们的代码中进行了必要的更改以将合规模式设置为 RFC2616，因为我们需要在我们的产品中支持多行标头。

这是我们设置它的方式：

我们已经使用以下代码成功验证了合规模式正在发生变化。

这会将合规模式打印为“RFC2616”。

但即使将合规模式设置为 RFC2616，我们仍然会看到这个问题。

我们通过中间的代理服务器访问我们的服务器代码。

我们无法弄清楚是什么原因造成的。

第 4 节，第 34 页：

可能有 5 个错别字，我想知道如何建议更新？注册不可用，因为您在 ietf.org 的帐户应该由……所谓的管理员审核。

PS我知道，RFC不应该经常更新，这些“问题”并不重要，但同样，这是一个基本的事情。它应该尽可能理想。

看来，自 Spring 5.0 以来，DateTime 格式：RFC2616中指定的 ANSI C 的 asctime() 在提供单个数字（即 9 而不是 09）时不再被正确解析。

查看测试方法时：Spring提供的 HttpHeadersTest.firstZonedDateTime() ；我们可以看到，对于“ANSI C 的 asctime() 格式”，提供了两位数（即 02）作为测试输入，而不是 RFC2616（3.3.1）中指定的一位数（即 2） ）。

我编写了一个测试方法来展示潜在的错误。

我希望上述测试即使对于单个数字输入也能断言为真。但正如您所见，通过运行测试方法，会引发错误：

使用调试器仔细查看时；错误可以追溯到：

从 Spring 5.0 开始，似乎正在应用一种解析 Header DateTime 的新方法。请参阅HttpHeaders.getFirstZonedDataTime(String headerName)：

我相信这个错误是在 Spring 5.0 中引入的，更具体地说是在private ZonedDateTime getFirstZonedDateTime(String headerName, boolean rejectInvalid)的这个循环中：

在查看最后一个功能构建时：Spring 4.3 使用了类似的循环：private long getFirstDate(String headerName, boolean rejectInvalid)

但是，尽管 Spring 4.3 仍然使用 java.text.SimpleDateFormat 进行解析，但从 Spring 5.0 开始，Java.time.format.ZonedDateTime 被用于解析。

Spring 4.3 和 Spring 5.0 都使用相同的私有静态数组进行迭代：

总结：

我相信从 Spring 5.0 开始引入了一个错误，其中在解析单个数字时不再正确解析 RFC2616 中定义的 ANSI C 的 asctime() 格式；

我相信错误的原因是从 simpleDateFormat 更改为 ZonedDateTime 进行解析。

我希望任何人在通过 Github 将其提交给 Spring 之前重现此错误；以确保我在测试用例或假设中没有犯任何错误。

这是我的第一篇文章; 原谅任何错误；欢迎（结构化）反馈。

我正在设计一个 REST API，我需要根据客户端提供的时间戳（反过来，将由API 在先前的响应中）。为此，我正在考虑使用 Last-Modified 和 If-Modified-Since 标头。

这里较早的问题（例如Is it valid to modify a REST API representation based on a If-Modified-Since header?）似乎表明这是不赞成的，因为RFC2616表明这些标头的目的与缓存有关. 但是，从那时起，RFC2616 已被RFC7232取代，其中指出

If-Modified-Since 通常用于两个不同的目的：1) 允许有效更新没有实体标签的缓存表示和 2) 将 Web 遍历的范围限制为最近更改的资源。

我的解释是，我允许检索自上次检索以来对集合的所有更改的用例包含在第二个目的中。

所以我有两个问题：

1. 这种解释是正确的，还是我在这里遗漏了一些微妙的东西？
2. 即使我的解释是正确的，以这种方式使用这些标题是否是一种好习惯？换句话说：还有什么其他原因不使用这些标头，例如，在响应中包含时间戳并允许客户端在下一个请求的查询字符串中提供该时间戳？

有人可以帮我提炼出关于标头的代理服务器（只是正向代理而不是反向）的最低要求吗？在代理服务器向上游传递之前，绝对必须从客户端请求中删除哪些标头？

我正在尝试理解rfc2616 文档，但它对我来说有点难以理解，而且我还没有找到任何博客或文章来隔离代理服务器对标头的要求或期望。

我使用 VS Code REST 客户端扩展有这个测试请求：

在接收端，在此端点上侦听的 NestJS 应用程序没有获取 PATCH 请求的主体，因此在负责更新请求的 NestJS 服务中没有更新。

这是 NestJS 中的控制器方法/端点：

以及上面调试控制台日志的结果：

谢谢！