Re: [PATCH] add DNT (Do Not Track) header

Am 27.06.2012 18:41, schrieb Alex Rousskov:
> On 06/27/2012 05:09 AM, Alexander Holler wrote:
>> Am 27.06.2012 12:57, schrieb Henrik Nordström:
>>> ons 2012-06-27 klockan 10:45 +0200 skrev Alexander Holler:
>>>>> Agreed. With the change to support arbitrary headers in
>>>>> request_header_access this patch is not needed. We could also forget
>>>>> many other less common headers.
>
>>>> It is, at least if people are using whitelists for headers which can
>>>> pass the proxy.
>
>>> With the patch to support arbitrary headers in request_header_access you
>>> can match any header, and having the header defined in the source is
>>> only an optimization for frequently accessed headers.
>
>> And it will require the need for a rewrite of the configuration and
>
> Would not both your patch and the general request_header_access patch
> require configuration changes?

No, the simple two-line-patch requires changes only if a
header-whitelist is used _and_ DNT should be on this list. It also
offers the possibility to use DNT in a blacklist environment, but I
would assume that DNT isn't a header someone should (or want to) blacklist.

>> doesn't help people which want or have to live with current versions.
>
> Both your patch and the general request_header_access patch can be
> applied to "current versions". I agree that your patch is a lot easier
> to port, of course. If general request_header_access is not backported,
> your patch may be accepted for those versions instead.
>
>
>> The patch was meant for the current (and maybe older) versions and I'm
>> just unable to understand the high resistance to include such a simple
>> two-line patch. Maybe the resistance is motivated by the header itself
>> and not the patch, I don't know and have to speculate.
>
> You do not have to speculate. The resistance, at least on my part, is
> motivated by the "death by thousands cuts" principle: Yes, we can
> hard-code explicit handling of hundreds of headers that Squid does not
> need to know about. Any single addition will help somebody and has
> negligible negative side effects on its own, but in aggregate, they make
> the code and performance worse.

Sorry, I don't understand about what you are talking. Squid already uses
hardcoded headers and the simple two-line patch just adds another one.
No magic, no code degradation, no new bad algorithm. It just completes
the already existing list of headers. It's that simple.

And that stupid patch should never have had engaged such a discussion,
otherwise I never would have sent it, I didn't want to discuss the
existing implementation with hardcoded headers nor did I want to discuss
some other patches or better approaches.

> This has nothing to do with the header itself. I know little about DNT,
> but my response would be the same if the header was named DT :-)
>
>
> BTW, do you or somebody you know run Squid with a white list of headers
> (denying all other headers)? I am curious if such an approach can work
> in a general deployment environment because it feels like it would break
> many benign applications behind a proxy.

I'm pretty sure whitelist configurations are used because of the second
idea in "The six dumbest ideas in computer security". Besides that such
an configuration is included (as comment) in the example configuration.

I don't know if those could be called "general deployment environments",
but in today times where the need for a proxy to spare some traffic is
often just non-existent, I'm not sure what a general deployment
environment for a proxy is at all. Not to mention the existing warning
(in the example configuration), that a white- or blacklist violates the
HTTP standard. But I assume configurations which are using the
[request|reply]_header_access directives can't be called "general
deployment environments".

Regards,

Alexander
Received on Sat Jun 30 2012 - 07:47:29 MDT