Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?

On 21/04/11 05:56, Jenny Lee wrote:
>
>> Reality after looking at the code:
>> Mangling is done after peer selection right at the last milli-second
>> before sending the headers down the wire. It is done on all HTTP
>> requests including CONNECT tunnels when they are relayed.
>>
>> Peering info *is* available. But "src" ACL does not check for that
>> property.
>>
>> If you have 3.1 I think you want to add a "peername" ACL like so:
>>
>> acl peerX peername X
>> request_header_access User-Agent allow OFFICE !peerX
>> ...
>
> I have 3.2.0.1 and unfortunately this does not work either. I will check on 3.2.0.7 (would that make a difference?).

May do. I don't recall changing anything there directly but the passing
around of request details has been fixed in a few places earlier which
may affect it.

Also, do you have this part which I forgot to add?
   cache_peer .... name=X

>
> Furthermore, it would be nice to able to select UA like:
>
> request_header_replace User-Agent OFFICE Mozilla
> request_header_replace User-Agent HOME IE

Well...

  request_header_access User-Agent deny OFFICE Mozilla
  request_header_replace User-Agent HOME IE

... should also be working if a "browser" type ACL is used to check the
User-Agent field for "Mozilla".

P.S.: Nice for some maybe, but which of the 3.5 million or more browser
U-A strings do you suggest we hard-code into Squid for faking like this?
  No, we picked to leave it optional and open for future browsers and
tools to be developed. Especially since it is a standard violation to
actually do any U-A changes. There are good reasons for *some* of those
sites behaviour and each piece of the U-A has significant meanings.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.7 and 3.1.12.1