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
