我在Apache下编写了一个运行在PHP中的IPP服务器。 与标准的IPP客户端，它工作得很好。 但是，当我尝试从iOS设备打印时，当客户端尝试切换到TLS时，连接中断。 这似乎被RFC 2817（在HTTP / 1.1中升级到TLS）所涵盖，并且应该由Apache支持多年。 我的Apacheconfiguration有什么问题？
Apache SSLconfiguration：
SSLEngine optional SSLCertificateFile /path/to/server.crt SSLCertificateKeyFile /path/to/server.key 请求：
OPTIONS * HTTP/1.1 Connection: Upgrade Host: iserv.local Upgrade: TLS/1.0,SSL/2.0,SSL/3.0 User-Agent: CUPS/1.5.0
回复：
HTTP/1.1 200 OK Server: Apache/2.2.16 Content-Length: 0 Content-Type: text/plain
预期回复：
HTTP/1.1 101 Switching Protocol Server: CUPS/1.4 Connection: Keep-Alive Keep-Alive: timeout=30 Connection: Upgrade Upgrade: TLS/1.0,HTTP/1.1 Content-Length: 0
据我所知，Apache Httpd从版本2.1开始支持RFC 2817 。
要使用它，必须使用SSLEngine optional （而不是更常见的SSLEngine on HTTPS ），如文档中所述。
编辑 （我没有意识到你已经使用SSLEngine optional ）：
看来这个问题是由于OPTIONS * HTTP/1.1 。 当你用相同的升级头发送OPTIONS / HTTP/1.1 （或者OPTIONS / HTTP/1.1 ）的时候它会工作。
经过一番调查，似乎OPTIONS *在最近版本的Apache Httpd上完全不起作用（或者至less它的工作方式不同）。
如果你尝试Debian Etch（Apache Httpd 2.2.3），一个简单的OPTIONS * HTTP/1.1 （带有一个Host头文件）会给你一个Allow: GET,HEAD,POST,OPTIONS和Vary头文件的响应。
在Debian Lenny（Apache Httpd 2.2.9，带有一些额外的后端安全补丁）以及更新的版本中，根本不会得到这些Allow或Vary标头。 你会得到他们OPTIONS / 。
我怀疑在这些版本之间处理OPTIONS *的方式有所改变。 （这也可能与此线程中提到的问题有关）。这肯定会影响通过OPTIONS *进行的RFC 2817升级。
我会build议询问Apache Httpd用户或可能的开发人员名单关于此。
这听起来可能是一个错误。 （ OPTIONS *使用非常less见，很less有客户端支持RFC 2817，因此它可能已经被忽略了。）