Tomcat是否受此漏洞影响？ 这是咨询公告 。
从本质上讲，这个漏洞使得Apache服务器对单个文件的请求构build了一个巨大的响应，远远大于文件本身。 虽然RFC（ 2616 ）告诉Web服务接受多个范围，但没有任何说明你不能有范围重叠。 在Apache方面不好的实现，但是其他Web服务器很可能是脆弱的。
大多数的Tomcat servlet不允许Range请求，因为这是一个自定义的filter实现，可以发送正确的内容块。 但是，默认的servlet（处理静态内容）是另一回事。
当前的Tomcat代码（ 在这里 ）接受多个范围集合，单独validation它们在文件大小的范围内，并将其放在要服务的范围列表中。 但是，范围从servlet的内部caching中依次stream出，如果请求数据的客户端断开连接，应该立即停止该进程; 在大多数情况下，这应该使重叠范围请求大致相当于服务大文件的性能影响。
而且，为了确认，快速testing..
我们会发送一个快速的请求来获取大小
请求：
HEAD / HTTP/1.1 Host: 192.168.100.200 Accept-Encoding: gzip Connection: close
响应：
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"1887-1314245401000" Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT Content-Type: text/html Content-Length: 1887 Date: Thu, 25 Aug 2011 04:18:05 GMT Connection: close
判决是1887字节的可爱的小“它的工作！” 页。 这就告诉我们在没有Tomcat的情况下，我们可以使用这个范围。
好的，我们来看看它是否允许快速重叠，字节0到10然后是5到15：
请求：
GET / HTTP/1.1 Host: 192.168.100.200 Range: bytes=0-10,5-15 Accept-Encoding: gzip Connection: close
响应：
HTTP/1.1 206 Partial Content Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"1887-1314245401000" Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY Content-Length: 224 Date: Thu, 25 Aug 2011 04:17:11 GMT Connection: close --CATALINA_MIME_BOUNDARY Content-Type: text/html Content-Range: bytes 0-10/1887 <?xml versi --CATALINA_MIME_BOUNDARY Content-Type: text/html Content-Range: bytes 5-15/1887 version="1 --CATALINA_MIME_BOUNDARY--
是的，果然 – <?xml versi version="1和version="1 。所以重叠的作品。
而且，它是否允许请求更多的数据，而不是实际上被提供的文件：
请求：
GET / HTTP/1.1 Host: 192.168.100.200 Range: bytes=0-1800,1-1886 Accept-Encoding: gzip Connection: close
响应：
HTTP/1.1 206 Partial Content Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"1887-1314245401000" Last-Modified: Thu, 25 Aug 2011 04:10:01 GMT Content-Type: multipart/byteranges; boundary=CATALINA_MIME_BOUNDARY Content-Length: 3893 Date: Thu, 25 Aug 2011 04:19:51 GMT Connection: close --CATALINA_MIME_BOUNDARY Content-Type: text/html Content-Range: bytes 0-1800/1887 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>Apache Tomcat</title> </head> ...(lots more data)...
是 – 几乎4KB服务的一个sub-2KB文件。
放大这种方法，包括大量的范围，这是攻击的基本结构。 在Tomcat的情况下，真正的影响似乎是它允许攻击者获得大量的数据，以响应对相对较小的资源的请求，这可能有助于针对拒绝服务的带宽。 我也怀疑其他边缘情况下的影响; 反向代理尝试caching206响应，或者当请求的资源是大于Tomcatcaching中的文件时。
它不是一个漏洞。 读取默认的servlet代码。 它加载一次资源。 它也读取所有的范围偏移量。 然后遍历原始资源上的内容库的所有偏移量。 这与apache httpd是如何做到的不同。 所以它不会触发OOMexception。
您可能会争辩说，您可以发送大量范围标题来制作详尽的列表或范围以返回。 但是，这是发送太多头的DOS攻击的一个具体例子。 在这种情况下，tomcat和httpd有办法限制太多的请求头以及它们的大小。
– 更新2011年10月4日 –
Tomcat可能会受到攻击，导致连接可能比正常时间更长。 但是这种攻击与标准DOS攻击没有区别。 它只是允许攻击者通过使请求提供比通常服务更多的字节来“更高效”。
这种攻击所消耗的唯一额外资源是带宽和开放式套接字连接。 所以这与标准的DOS攻击没有什么不同。 唯一的区别是攻击者可以稍微高效。 但是你没有获得任何额外的保护，让Tomcat尝试在范围上执行额外的validation。
tl; dr：可能不是。
鉴于Apache的httpd和Tomcat是不同的产品，我找不到在Tomcat中提到等效的漏洞公告，我倾向于“不”。 在公告中没有详细说明确切的错误是什么，所以很难说这可能是一个常见的编程错误，还是Apache httpd特有的东西。