Chris Woodfield wrote:
> So now that this behavior has a name, I looked and noticed that per the 
> 2.7 docs, collapsed_forwarding defaults to off, and isn't enabled in our 
> config either. Does running squid in reverse proxy mode implicitly turn 
> this on?
Yes. It's designed for primary use in reverse proxies and the setting is 
to explicitly turn it on for forward proxies as well.
Amos
> 
> -C
> 
> On Apr 10, 2009, at 12:26 AM, Amos Jeffries wrote:
> 
>> Chris Woodfield wrote:
>>> Hi,
>>> I've noticed that either by design or as a side-effect of squid's 
>>> caching that if I request the same object from multiple clients at 
>>> the same time, squid will effectively "multiplex" the transfer - that 
>>> is, use a single transfer from origin to feed the object to each 
>>> client as it receives the incoming http transfer. IMO this is a Good 
>>> Thing.
>>> I'm wondering if it's possible to extend this behavior to a 
>>> non-caching proxy - this would allow the utilization of squid as a 
>>> non-caching CARP proxy while protecting a parent from large numbers 
>>> of requests for a single object (which in a CARP setup would normally 
>>> all get sent to the same parent, potentially overloading it).
>>> So the goal is to utilize this multiplexing capability in squid while 
>>> not actually caching the content. However, testing shows that when I 
>>> disable disk caching (via "cache_dir null" or by "maximum_object_size 
>>> 0 KB", this behavior is no longer present.
>>
>> Correct. This is the collapsed forwarding feature at work. It 
>> currently requires a disk copy to be used as intermediary source so 
>> that all clients can get at it.
>>
>> I've added your info to the known shortcomings section of the wiki so 
>> that when it gets re-written for 3.x this issue can be resolved.
>>
>> Amos
>> -- 
>> Please be using
>>  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
>>  Current Beta Squid 3.1.0.6
>>
> 
-- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13 Current Beta Squid 3.1.0.6Received on Sat Apr 11 2009 - 03:30:08 MDT
This archive was generated by hypermail 2.2.0 : Sat Apr 11 2009 - 12:00:02 MDT