php – Apache模块：实现100-Continue

2023年9月21日 289次阅读

Supporting HTTP 100 Continue with PHP在2010年提出这个问题的重点略有不同(它寻求的是PHP解决方案,而不是Apache解决方案),但从未解决过.

上下文

HTTP / 1.1规范创建了请求标头’Expect’,它有一个定义的值;即’100-Continue’. 2014年6月发布的修订后的HTTP / 1.1 RFC(见RFC 7231 Section 5.1.1)声明如下：

A 100-continue expectation informs recipients that the client is about
to send a (presumably large) message body in this request and wishes
to receive a 100 (Continue) interim response if the request-line and
header fields are not sufficient to cause an immediate success,
redirect, or error response. This allows the client to wait for an
indication that it is worthwhile to send the message body before
actually doing so, which can improve efficiency when the message body
is huge or when the client anticipates that an error is likely (e.g.,
when sending a state-changing method, for the first time, without
previously verified authentication credentials).

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

…However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented by many servers…

重点是我的,而不是规范

即使不包括此标头的扩展机制,100-continue值似乎也很难实现.如果我们考虑标准的PHP / Apache堆栈,Apache会在客户端请求时提供100-continue临时响应.

但是,它完全基于它自己的请求处理,即没有咨询PHP资源.这似乎打败了标头的目的,因为大多数请求都会因无效的请求参数或权限而失败;不是由于格式错误的HTTP请求.因此,即使客户端声明100-continue期望并收到100-continue响应,也不意味着请求头是有效的.

意向

作为更全面实施HTTP规范的更广泛意图的一部分(为了提高网络效率,安全性和清晰度),我打算在发送100-continue响应之前更正确地验证请求标头.

这意味着必须将请求传递给我的PHP资源控制器才能在发送100-continue响应之前进行验证.这允许在客户端浪​​费时间和资源发送大型邮件正文之前识别无效参数和不正确的权限.

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

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-continue响应之前立即挂钩请求,并执行将请求头传递给PHP资源的附加步骤解析.

从那里,正常的Apache处理可以恢复,发送100-continue响应,Apache等待消息体,然后将完成的请求传递给PHP资源.

问题

>如上所述的Apache模块是否会改进当前的实现？
>过去是否有任何模块试图解决这个问题？

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

>有哪些Apache钩子可用？我找不到标识可用挂钩的资源以及它们的处理顺序.找到了
Apache2: Apache Hooks
> Apache模块应该如何与PHP交互？我知道它取决于安装方法(例如Apache进程中的多个线程或每次执行的单个进程等).但我不确定Apache如何管理其与PHP进程的其他交互.

最佳答案 您描述的内容不适用于大多数处理程序,包括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

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

客户端代码没有什么区别.

但是假设你有一大批开发人员和测试人员没有比开发你提出的模块更好的事情,并且它不需要对处理程序进行大量更改,或者上述处理程序的维护人员为自己的期望/ 100建立支持…为什么我可以,因为当我可以获得相同的结果而不必安装其他模块时,网络服务器管理员想要安装这样的模块,增加我的网络服务器的攻击面并调整我已经使用的任何代码吗？

点赞