感谢kangaroo_egg(袋鼠蛋)能如此认真地对Apusic 4.0有这样深入的测试，虽然有点鸡蛋里面挑骨头，但仍表示感谢，毕竟这样可以使Apusic更加完善。下面我对你所提出的问题做一些解答：1. 关于HTTP头部多余空行的问题
我再次仔细查阅了RFC 2068，第5.1节The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF因此Apusic这样做并没有错，而且没有任何浏览器会发送这样的请求。Apusic是支持持久连接的，当你在发送第一个请求并要求keep-alive之后，后续请求之间可以包含任意多的空行，这点可以很容易写程序验证。Apusic在接收到CRLF之后立即关闭请求还有另外一个原因。Apusic是支持多路复用的，即在同一个端口下允许使用多种协议，并不仅限于HTTP。例如目前Apusic在缺省的6888端口下就支持HTTP, IIOP, JMS等多种协议，而且是可扩充的。实现多路复用的基本原理就是检测输入流的头几个字节，进而判断出协议类型。由于没有任何协议是以CRLF打头的，因此Apusic抛弃了这一连接请求。2. 断点续传（分范围请求）的问题。由于Apusic首先是一个J2EE应用服务器，其Web Server更多地是一个Servlet和JSP容器，文件传输并不是它的强项，但这并不表示Apusic不支持断点续传，这点用falshget就可以很容易验证，而不需要写什么程序。3. 对于JSP语法错误IE只会显示自己的500错误信息的问题，我们是按照标准HTTP协议来实现的，所以并没有针对IE做任何处理。如果你想在IE中看到错误信息其实也很简单，只需在IE中打开
工具->Internet选项->高级->浏览->显示友好HTTP错误信息
将上面的勾去掉就行了。IE只认为它的错误信息是"友好"的，别人的都是"不友好"的，它这么霸道，我们也没办法。4. 对于以下的JSP代码
<%int i = 0;%>
<%在我这里是会报错的，烦请你再确认一下。5. 关于JSP文件错误行定位的问题，我们是尽可能地将Java编译出错位置与JSP源文件对应起来，在大多数情况下这种对应关系都很准确，甚至在运行过程中抛出的异常都能将出错位置指向JSP源文件，这在其他应用服务器中是见不到的。但有时这种对应关系并不能100%准确，针对你提出的特例我们将尽快予以改进。6. 中文文件名的和文件名中包含空格的问题，我们正在处理。7. 服务器是否支持可以防止过量http头信息的问题，非常感谢你为我们发现了一个较为严重的bug，我们会尽快发布安全补丁。
世界上没有任何一个软件是十全十美的，发现并解决问题不仅不会对软件造成伤害，反而会使软件向更好的方向发展。我相信国外同行们看到我们这些问题肯定不会耻笑我们，相反会善意地指出我们的问题，帮助我们改进。一个心态良好的程序员绝不会回避程序中存在的错误和缺陷，相反，每发现一个程序中的错误都会感到很兴奋，因为这个程序的稳定性又将要提高了。
我再次仔细查阅了RFC 2068，第5.1节The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF因此Apusic这样做并没有错，而且没有任何浏览器会发送这样的请求。Apusic是支持持久连接的，当你在发送第一个请求并要求keep-alive之后，后续请求之间可以包含任意多的空行，这点可以很容易写程序验证。Apusic在接收到CRLF之后立即关闭请求还有另外一个原因。Apusic是支持多路复用的，即在同一个端口下允许使用多种协议，并不仅限于HTTP。例如目前Apusic在缺省的6888端口下就支持HTTP, IIOP, JMS等多种协议，而且是可扩充的。实现多路复用的基本原理就是检测输入流的头几个字节，进而判断出协议类型。由于没有任何协议是以CRLF打头的，因此Apusic抛弃了这一连接请求。2. 断点续传（分范围请求）的问题。由于Apusic首先是一个J2EE应用服务器，其Web Server更多地是一个Servlet和JSP容器，文件传输并不是它的强项，但这并不表示Apusic不支持断点续传，这点用falshget就可以很容易验证，而不需要写什么程序。3. 对于JSP语法错误IE只会显示自己的500错误信息的问题，我们是按照标准HTTP协议来实现的，所以并没有针对IE做任何处理。如果你想在IE中看到错误信息其实也很简单，只需在IE中打开
工具->Internet选项->高级->浏览->显示友好HTTP错误信息
将上面的勾去掉就行了。IE只认为它的错误信息是"友好"的，别人的都是"不友好"的，它这么霸道，我们也没办法。4. 对于以下的JSP代码
<%int i = 0;%>
<%在我这里是会报错的，烦请你再确认一下。5. 关于JSP文件错误行定位的问题，我们是尽可能地将Java编译出错位置与JSP源文件对应起来，在大多数情况下这种对应关系都很准确，甚至在运行过程中抛出的异常都能将出错位置指向JSP源文件，这在其他应用服务器中是见不到的。但有时这种对应关系并不能100%准确，针对你提出的特例我们将尽快予以改进。6. 中文文件名的和文件名中包含空格的问题，我们正在处理。7. 服务器是否支持可以防止过量http头信息的问题，非常感谢你为我们发现了一个较为严重的bug，我们会尽快发布安全补丁。
世界上没有任何一个软件是十全十美的，发现并解决问题不仅不会对软件造成伤害，反而会使软件向更好的方向发展。我相信国外同行们看到我们这些问题肯定不会耻笑我们，相反会善意地指出我们的问题，帮助我们改进。一个心态良好的程序员绝不会回避程序中存在的错误和缺陷，相反，每发现一个程序中的错误都会感到很兴奋，因为这个程序的稳定性又将要提高了。
要不怎么才能让我们的软件越来越好呢。
布署项目的时候，出现了问题，还要考虑是否应用服务器在出问题，哪就惨了!!!
我认为，这几项测试反应出的问题，不是小问题，说明设计者设计不周。由此推测，主要功能模块，会不会也有更严重的而他们没有发现的问题呢？