Apache模块：实现100继续 [英] Apache Modules: Implementing 100-Continue

问题描述

支持HTTP 100继续与PHP 在2010年提出了这个问题回略有不同的侧重点（它寻求一个PHP的解决方案，而不是一个Apache的解决方案），但从来没有得到解决。

上下文

在HTTP / 1.1规范创建的请求头'期待'里面有一个限定值;即100继续。修订后的HTTP / 1.1的RFC（见 RFC 7231第5.1.1节）在2014年6月发布声明如下：

  

一个100-继续期望通知收件人客户端是约
  发送（presumably大）消息体中这一要求和愿望
  接收100（继续）临时响应，如果请求线和
  头字段都不足以导致立即成功，
  重定向或错误响应。这允许客户端等待的
  迹象表明，这是值得发送邮件正文之前
  其实这样做，可以提高工作效率，当邮件正文
  是巨大的或者当客户端预计的误差是可能的（例如，
  发送时的状态变化的方法，对于第一次，没有
  previously验证身份验证凭据）。

这也是一个普遍接受的声明，本说明书的这一部分都是由服务器和客户端被不完全实施。修订后的规范，甚至暗示是：

  

......然而，扩展机制尚未客户端使用的以及不能了解的需求还没有被许多服务器实施 ...

的强调的是我的，不是从规范的

即使排除这个标题的扩展机制，100继续价值似乎也执行不力。如果我们考虑一个标准的PHP / Apache的堆栈，阿帕奇确实提供了100继续临时响应，如果客户端请求它。

然而，这是否完全基于其自身的要求，即处理没有咨询的PHP资源。这似乎打败头的目的，大多数请求将由于无效的请求参数或权限失败;不是由于畸形的HTTP请求。因此，即使客户端声明100继续期望并接收一个100继续响应，这并不意味着该请求头是有效的。

意向

作为一个更广泛的意向更充分地实现HTTP规范（为宗旨，提高网络的效率，安全性和清晰度）的一部分，我打算送一个100继续响应之前更正确地验证请求标头。

这意味着请求必须传递给我的PHP资源控制器100继续响应发送之前进行验证。这使得无效的参数和不适当的权限到客户端浪费时间和资源发送大量邮件正文之前予以确定。

我期望交流将是这个样子：

 客户端Apache资源
 - ＆GT; | | |
  | ------请求头------＆GT; | |
  | |  -  [解析] |
  |＆LT; ----- 400错误的请求---- | |
  | |  -  [线路] |
  | | -------请求头--------＆GT; |
  | | |  -  [验证]
  | |＆LT; ---错误/ 100继续---- |
  |＆LT;  - 错误/ 100 Continue-- | |
＆LT;  -  | [结束或...] | |
  | ------请求体------＆GT; | |
  | | --------完整的请求-------＆GT; |
  | | |  - 【工艺】
  | |＆LT; --------- ----------回应|
  |＆LT; -------- --------回应| |
＆LT;  -  | | |
 

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

策略

由于需要集成的程度，唯一的解决办法看来是Apache模块/延伸旨在之前立即100继续响应被发送，并执行将请求传递头向的附加步骤挂钩到请求PHP资源解析。

在这里，正常的Apache处理可以恢复，与100继续发送，阿帕奇等待邮件正文，然后传递完成的请求到PHP资源响应。

问题

1. 请问如上所述是改进当前实现Apache模块？




2. 是否有寻求在过去解决这个任何模块？

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

<醇开始=3>

什么阿帕奇挂钩可用？我找不到标识可用钩和在其中它们被处理的顺序的一个资源。实测它
的Apache2：Apache的钩

如何应Apache模块用PHP？交互我知道它取决于（Apache的进程或每个执行单个进程等内如多线程）的安装方法。但我不确定的Apache如何准确地管理与PHP进程的其他交互。

解决方案

在描述什么是不会与大多数处理程序，包括PHP工作。 HTTP是一个基于消息的协议，通常它的请求 - 应答方法 - 唯一的例外是连接请求，网络插槽和期望/ 100的回应。因此，实现这将需要重新设计Web服务器的内部，接口（S）的处理程序和处理程序本身：用于CGI，FastCGI的和ISAPI模块PHP没有看到该请求，直到它在Web服务器被整理。

，你将不得不实现自己的客户端太（至少一个AJAX / JavaScript的SJAX）。

考虑，而不是pre-档期您的要求：

 客户：我可以发送一个非常大的文件？
 服务器：204
 客户：这里是一个真正的大文件
 

有只有一个额外的套头，特别是没有多余的RTT与期待/ 100法相比。花一些时间来计算每个请求产生的成本。这是很小的。它将所有的服务器今天的工作。它不采取大力发展个月。
不希望得到的替代解决方案的问题的细节过于胶着，显然我们希望的URL是在客户端的请求是相同的，因此在2客户端请求的意图的差异将需要前$ P $别处pssed，例如：通过使用OPTIONS动词的第一个请求和PUT / POST / GET / DELETE在第二位。

有没有在客户端code此相差不大。

但假如你有开发者和一无所有测试的军队不是开发你提出的模块好做，而且它并不需要对处理或上述处理程序的维护者广泛的变化建立支持期望/ 100本身。 ..为什么要我作为Web服务器管理员要安装这样的模块时，我可以得到相同的结果，而无需安装额外的模块，增加我的web服务器的受攻击面，适应我已经使用任何code？

Supporting HTTP 100 Continue with PHP raised this issue back in 2010 with a slightly different focus (it sought a PHP solution as opposed to an Apache solution) but was never resolved.

Context

The HTTP/1.1 specification created the request header 'Expect' which has one defined value; namely '100-Continue'. The revised HTTP/1.1 RFCs (see RFC 7231 Section 5.1.1) released in June 2014 state the following:

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).

It is also a generally accepted statement that this part of the specification has been imperfectly implemented both by servers and by clients. The revised specification even alludes to this:

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

emphasis is mine, not from the specification

Even excluding the extension mechanism for this header, the 100-continue value also seems to be poorly implemented. If we consider a standard PHP/Apache stack, Apache does provide the 100-continue interim response if the client requests it.

However, it does this based solely on its own processing of the request, i.e. without consulting the PHP resource. This seems to defeat the purpose of the header as most requests will fail due to invalid request parameters or permissions; not due to a malformed HTTP request. So, even if the client declares a 100-continue expectation and receives a 100-continue response, it does not mean that the request head is valid.

Intention

As part of a broader intention to more fully implement HTTP specification (for the purpose improved network efficiency, security, and clarity), I intend to more properly validate the request header before sending a 100-continue response.

This means that the request must be passed to my PHP resource controller to be validated before the 100-continue response is sent. This allows invalid parameters and improper permissions to be identified before the client wastes time and resources sending a large message body.

I expect that the exchange would look something like this:

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--------|                            |
<-|                         |                            |

Obviously, this requires greater inter-operation between the PHP application and the apache web server.

Strategy

Due to the extent of the integration required, the only solution appears to be an Apache module/extension designed to hook into the request immediately before the 100-continue response is sent and perform the additional step of passing the request head to the PHP resource for parsing.

From there, normal Apache processing can resume, with the 100-continue response being sent, Apache waiting for the message body and then passing the completed request to the PHP resource.

Questions

1. Would an Apache module as described above be an improvement to the current implementation?

2. Are there any modules that have sought to address this in the past?

Also, regarding the technical details of developing Apache modules:

3. What Apache hooks are available? I cannot find a resource that identifies the available hooks and the order in which they are processed. Found it Apache2: Apache Hooks

4. How should an Apache module interact with PHP? I am aware that it depends upon the installation method (e.g. multiple threads within the Apache process or individual processes per execution etc.). But am unsure of how exactly Apache manages its other interactions with PHP processes.

解决方案

What you describe is not going to work with most handlers, including PHP. HTTP is a message based protocol, and normally its a request-reply method - the only exceptions being the connect request, web sockets and the expect/100 response. Hence implementing this will require re-engineering the internals of the webserver, the interface(s) to the handler and the handler itself: for CGI, fastcgi and the isapi module PHP does not see the request until it has been marshalled in the webserver.

And you will have to implement your own client too (at least as an AJAX/SJAX JavaScript).

Consider instead pre-flighting your request:

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

There is only a single extra set of headers, notably no extra RTT compared with the expect/100 method. Take some time to calculate the resultant cost per request. It's tiny. And it will work with all servers today. And it doesn't take months of effort to develop. Without wishing to get too bogged down in the details of an alternative solution to the problem, clearly we would want the URL to be the same in both client requests, so the difference in intent of the 2 client requests would need to be expressed elsewhere, e.g. by using the OPTIONS verb in the first request and PUT/POST/GET/DELETE in the second.

There's little difference in the client code for this.

But supposing you have an army of developers and testers with nothing better to do than develop your proposed module, and that it does not require extensive changes to the handlers or that the maintainers of aforesaid handlers build support for expect/100 themselves... Why should I, as webserver admin want to install such a module when I can get the same result without having to install additional modules, increase the attack surface of my webserver and adapt any code I am already using?

这篇关于Apache模块：实现100继续的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！