> 2008/9/22 Alex Rousskov <[EMAIL PROTECTED]>: > >> >> 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 >
