Re: [RFC] bandwidth savigns via header eliding

On 07/18/2014 11:37 PM, Amos Jeffries wrote:
> On 19/07/2014 2:55 a.m., Alex Rousskov wrote:
>> On 07/18/2014 01:32 AM, Amos Jeffries wrote:
>>> I have wondered about creating a registry of known garbage and simply
>>> dropping those headers on arrival in the parser. This would be in
>>> addition to the header registry lookup and masking process we have for
>>> hop-by-hop headers.

>> We already have squid.conf options to drop headers. Folks that want to
>> focus on saving bandwidth may use them. We can publish the corresponding
>> configuration excerpts on the wiki.
>>
>> If those options are not enough, let's add more. If those options slow
>> Squid down too much, let's discuss optimizations (keeping in mind that
>> much better optimizations can probably be obtained by preserving header
>> blobs during forwarding).
>>
>> However, please do not hard-code policing of messages Squid can grok,
>> especially in the parser.

> See my post in reply to Eliezer.

Your reply to Eliezer does not address my concern: Why should we avoid
the existing configuration interface that already allows folks to drop
what they want to drop?

> But the connection: and content-length header mangling, and
> some of the other security bypasses have deeper implications and special
> processing may be needed to cleanup properly.

Special identification code may indeed be needed for mangling cases, but
it can be integrated with the existing configuration nicely. If you want
to add code that would identify "mangled" Connection and Content-Length
headers, that code can be engaged using something like a
Mangled-Header-Name or %Mangled-Header-Names request_header_access
parameter.

We can then discuss whether it is a good idea to use that configuration
by default (which is a separate decision IMO, see further below).

> ie drop a cneonction:
> header and also drop any it lists just to be safe,

This does not sound like a bandwidth savings feature, but Squid can
indeed be taught to drop headers listed by the mangled Connection
header. This behavior can be triggered automatically if Squid is
dropping a mangled Connection header.

> or reject requests with cteonnt-length: header in self defense.

Rejecting requests goes even further from the original RFC, but I
believe we have configuration options to do that as well.

Going forward, I suggest the following discussion format:

For each header (or an algorithmically defined group of headers):

a) Why does anybody may want to drop this header?

b) How do we want to tell Squid that the header should be dropped?
   Hard-coded decision, existing squid.conf directives, other?

c) What should be the default behavior? Drop or leave "as is"?

d) Any side actions if the header is dropped? For example, should we
also drop the headers the dropped header lists?

HTH,

Alex.
Received on Sat Jul 19 2014 - 18:06:48 MDT