Re: [MERGE] Connection pinning patch

> 2008/9/22 Alex Rousskov <rousskov_at_measurement-factory.com>:
>
>>
>> It would help if there was a document describing what connection pinning
>> is and what are the known pitfalls. Do we have such a document? Is RFC
>> 4559 enough?
>
> I'll take another read. I think we should look at documenting these
> sorts of features somewhere else though.

My reading of it, is that it works very similar to keep-alive. But limits
the alive connection to prevent collapsed forwarding over it or re-use by
other clients.
The impact on Squid-3 should be very minimal at this point, since we don't
yet have collapsed forwarding. This is though a pre-requisite of a good
collapsed design for Squid-3, which is high priority for 3.2.

As Christos said, its far more widely used for internal networks than
Internet. Going by the squid-users traffic it's starting to be the biggest
squid upgrade blocker at present.

>
>> If not, Christos, can you write one and have Adrian and others
>> contribute pitfalls? It does not have to be long -- just a few
>> paragraphs describing the basics of the feature. We can add that
>> description to code documentation too.
>
> I'd be happy to help troll over the 2.X code and see what its doing.
> Henrik and Steven know the code better than I do; I've just spent some
> time figuring out how it interplays with load balancing to peers and
> such.
>
>> ICAP and eCAP do not care about HTTP connections or custom headers. Is
>> connection pinning more than connection management via some custom
>> headers?
>
> Nope; it just changes the semantics a little and some code may assume
> things work a certain way.
>
>> Sine NTLM authentication forwarding appears to be a required feature for
>> many and since connection pinning patch is not trivial (but is not huge
>> either), I would rather see it added now (after the proper review
>> process, of course). It could be the right icing on 3.1 cake for many
>> users. I do realize that, like any 900-line patch, it may cause problems
>> even if it is reviewed and tested.
>
> *nodnod* I'm just making sure the reasons for pushing it through are
> recorded somewhere during the process.
>
>
>
> Adrian
>
Received on Mon Sep 22 2008 - 00:48:47 MDT