On Sunday, June 16, 2013 03:38:40 AM Amos Jeffries wrote: > On 16/06/2013 3:34 a.m., CACook wrote: > > On Saturday, June 15, 2013 09:38:56 PM Amos Jeffries wrote: > > > >> Because that is just a documentation example detailing which headers the > >> old obsolete feature "http_anonymizer paranoid" would remove and how to > >> setup the current header removal feature to behave the same. Since that > >> old feature existed things have moved on, both in Squid configuration > >> abilites, HTTP protocol specifications, and Squid support for those > >> specifications. > > And thanks for not updating the config file. > > And double-thanks for not giving a hint here how to set up for the new system. > > The problem is simply that _nobody_ with any interest in anonymous > proxies has submitted any updates to that section in many years. I did > go through recently and split the request/reply header lists properly to > remove invalid details from the description, but I have no interest in > anonymous proxies myself so going through the difficulty of researching > all the headers involved with privacy and anonymization and what all > their effects are is not something I'm interested in spending time on. > > As someone in the group benefiting from the feature do you yourself have > any contributions towards the documentation? > Textual suggestions are welcome, patches against src/cf.data.pre even > more so. > > NOTE: If left to me (it *is* on my todo list somewhere ahead to document > my experiences in the area), I would do something along the lines of a > wiki page (http://wiki.squid-cache.org/Features/ClientPrivacy) and > removing the examples from the config file entirely. I have strong > opinions about the difference between anonymity and privacy and how > important that difference is. So what you ended up with as documentation > might shock or not meet your needs. > > > After many inquiries here I find that information here is a jealously-guarded secret. I don't know what you guys have against one another, but it is crippling Squid. > > As one of the people who spends all day answering questions without > remuneration of any kind I find this quite saddening that you have that > opinion. What knowledge exists has been at your disposal. I've even been > druging through the code to find out what might be causing the strange > symptoms you describe, but found nothing yet... > The parser for both request_header_access and request_header_replace > begin by parsing the header name then looking up the *same* list of > objects to see if a mangler for that header already exists - creating > one if missing, then add the current lines details to the result for > controlling what happens to the header. Both paths seem to result in an > entry with a mangler existing regardless of the location and relative > positions of either of the request_header_* lines which you have > reporting as "not working" outside of a specific alignment. > The *one* limitation on these manglers is that if there is no > request_header_access list for the same header the replacement does not > get run. Which if you recall was the meat in my first response. > > > On the topic of anonymity and help with anonymous proxy configuration; > Sadly it *is* the one topic you are most likely never to get people > openly posting lots of details about. The ones who know most are > unlikely to want their details permanently distributed on this list > archive. Unlike proper privacy when a "trick" or protection of anonymity > is outed it drops in usefulness as "them" learn about it and devise (). > Everybodies opinions of what headers should be added/removed or > replaced (and with what) is different. Removing and altering other > services headers is itself a violation of the HTTP specifications by the > proxy. So everybody who actually *uses* these directives is pretty much > abusing HTTP. "We the Project" don't offer an official opinion or > recommendation about should or should not for most headers - as > demonstrated by that config file text being a simple notice of the old > features deprecation and a list of what the old feature did in terms of > the new one, not an endorsement or guarantee of any header in it. > In short you are left to devise the method for your own anonymity - we > can but help if some specific goes wrong. > > Amos I didn't know that you had spent any but a brief consideration of the anonymized headers. Thanks for your effort. It is surprising that so little information is known in this area. This is the reason for my discouragement. I am a real estate developer not a coder, so am only in a position to ask for guidance and follow instructions. I'll give up on this effort for now.