Apache模块：实现100-Continue

Question

用HTTP支持HTTP 100 Continue with PHP在2010年提出了这个问题，重点稍有不同（它寻求的是PHP解决方案，而不是Apache解决方案），但从未解决。

语境

HTTP / 1.1规范创建了请求标头“ Expect”，该标头具有一个已定义的值；即“ 100-继续”。2014年6月发布的修订版HTTP / 1.1 RFC（请参阅RFC 7231第5.1.1节）规定如下：

100连续期望值通知接收者该客户端即将在此请求中发送（可能很大）消息正文，并且如果请求行和标头字段不足以导致立即发送，则希望接收100（连续）临时响应成功，重定向或错误响应。这允许客户端在实际发送之前等待值得发送消息正文的指示，这可以提高效率，当消息正文很大或客户端预计可能发生错误时（例如，在发送状态时）第一次更改方法，而无需事先验证的身份验证凭据。

这也是一个普遍接受的声明，说明该部分的内容已被服务器和客户端完美地实现了。修订后的规范甚至暗示了这一点：

...但是，客户端尚未使用扩展机制，许多服务器尚未实现必须理解的要求 ...

重点是我的，而不是规范

即使不包括此标头的扩展机制，100连续值似乎也实现不佳。如果我们考虑使用标准的PHP / Apache堆栈，那么如果客户端请求，Apache会提供100个连续的临时响应。

但是，它仅基于自己对请求的处理来执行此操作，即无需咨询PHP资源。这似乎违反了标头的目的，因为大多数请求由于无效的请求参数或权限而失败；并非由于HTTP请求格式错误。因此，即使客户端声明了100个连续的期望并收到100个连续的响应，也并不意味着请求头是有效的。

意向

为了更全面地实现HTTP规范（旨在提高网络效率，安全性和清晰度），我打算在发送100个继续响应之前更正确地验证请求标头。

这意味着在发送100个继续响应之前，必须将请求传递到我的PHP资源控制器以进行验证。这样可以在客户端浪​​费时间和资源发送大型邮件正文之前，识别出无效的参数和不正确的权限。

我希望交换看起来像这样：

Client                    Apache                      Resource
->|                         |                            |
  |------Request Head------>|                            |
  |                         |-[Parse]                    |
  |<-----400 bad request----|                            |
  |                         |-[Route]                    |
  |                         |-------Request Head-------->|
  |                         |                            |-[Validate]
  |                         |<---Error / 100 Continue----|
  |<--Error / 100 Continue--|                            |
<-|[End or...]              |                            |
  |------Request Body------>|                            |
  |                         |--------Full Request------->|
  |                         |                            |-[Process]
  |                         |<---------Response----------|
  |<--------Response--------|                            |
<-|                         |                            |

显然，这需要PHP应用程序与apache Web服务器之间进行更大的互操作。

战略

由于所需集成的程度，唯一的解决方案似乎是一个Apache模块/扩展，旨在在发送100个继续响应之前立即挂接到请求，并执行将请求头传递给PHP资源的附加步骤，以实现以下目的：解析。

从那里开始，正常的Apache处理可以恢复，发送100连续响应，Apache等待消息正文，然后将完成的请求传递给PHP资源。

问题

1. 如上所述的Apache模块是否可以改善当前的实现？

2. 过去有没有试图解决这个问题的模块？

另外，关于开发Apache模块的技术细节：

3. 有哪些Apache钩子可用？我找不到标识可用钩子及其处理顺序的资源。找到它 Apache2：Apache Hooks

4. Apache模块应如何与PHP交互？我知道这取决于安装方法（例如Apache进程中的多个线程或每个执行中的单个进程等）。但是不能确定Apache如何精确地管理其与PHP进程的其他交互。

Answer 1

您所描述的内容不适用于大多数处理程序，包括 PHP。HTTP 是基于消息的协议，通常它是一种请求-回复方法 - 唯一的例外是连接请求、Web 套接字和 Expect/100 响应。因此，实现这一点需要重新设计 Web 服务器的内部结构、处理程序的接口以及处理程序本身：对于 CGI、fastcgi 和 isapi 模块，PHP 在请求被编组到 Web 服务器之前不会看到该请求。

而且您还必须实现自己的客户端（至少作为 AJAX/SJAX JavaScript）。

请考虑预先处理您的请求：

 Client: can I send a really big file?
 Server: 204
 Client: here's a really big file

只有一组额外的标头，特别是与 Expect/100 方法相比，没有额外的 RTT。花一些时间来计算每个请求的最终成本。它很小。今天它将适用于所有服务器。而且不需要花费数月的努力来开发。不希望过多地陷入问题替代解决方案的细节中，显然我们希望两个客户端请求中的 URL 相同，因此两个客户端请求的意图差异需要在其他地方表达，例如，在第一个请求中使用 OPTIONS 动词，在第二个请求中使用 PUT/POST/GET/DELETE。

客户端代码对此几乎没有什么区别。

但是，假设您有一支由开发人员和测试人员组成的军队，除了开发您提议的模块之外没有什么更好的事情可做，并且它不需要对处理程序进行大量更改，或者上述处理程序的维护者自己构建对expect/100的支持......为什么作为网络服务器管理员，当我无需安装其他模块就能获得相同的结果、增加网络服务器的攻击面并调整我已经使用的任何代码时，我是否应该安装这样的模块？