Summary:
overlapping multipart ranges causes Apache to spawn multiple process
threads and DoS the server RAM and CPU capacities with one or few HTTP
requests. Major for them.
We had complaints/issues related to this with Squid a few years ago.
While we do not have anything like the RAM and CPU issues (AFAIK), the
bandwidth consumption part of the problem still occurs.
IIRC we decided against compacting ranges due to issues with Adobe
reader products combined with a lack of clear RFC support to stand on.
I'm wondering which road we should go down and would like opinions from
the rest of you. These are just the first choices that come to mind,
other ideas welcome:
1) nothing. pass 206 replies straight through. continue to serve HIT in
the specified range sizes and order.
Pros: not our fault when things go wrong.
Cons: users wont care about that. remains hard to cache.
2) re-structure range parts on the fly. Possibly due to ACL or config
options.
Pros: happy clients with broken agents.
we can emit Warning headers.
Cons: more CPU consumed, would require disker backing to avoid the
RAM vulnerability that hit apache.
No incentive for clients to ever get fixed.
HTTPbis seem to be working towards requiring range compacting
and maybe reordering.
3) answer with compacted ranges ourselves to HITs.
Pros: bandwidth savings. service time savings. can be implemented in
days.
Cons: unhappy clients when using broken agents.
4) join (2)+(3): re-structure requested ranges but pass reply back as
given by the server.
Pros: less resource consumption. Net bandwidth savings.
Cons: potentially breaks client agents?
Is the Adobe reader problem still valid today? Anyone aware of other
clients doing similar things?
Amos
