On 08/31/2011 01:39 AM, Amos Jeffries wrote: > 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?
If there is no real demand for these changes other than our general desire to better Squid, than I vote for #1, its biggest "pro" being that it is already implemented. If are real users asking for a specific related feature/optimization, then I would do #2 and/or #3 (but not #4 if I understand it correctly), each controlled by ACLs to bypass broken agents and guided by specific user needs. For example, if a user wants #3 but not #2, then just do #3 with ACLs but do not implement #2. HTH, Alex. > Is the Adobe reader problem still valid today? Anyone aware of other > clients doing similar things? > > > Amos
