Re: [RFC] Upgrade for via cofnig setting

On 21/04/2013 4:20 a.m., Alex Rousskov wrote:
> On 04/20/2013 05:53 AM, Amos Jeffries wrote:
>> The Via header is one of the important headers for signalling end-to-end
>> path properties for an HTTP request and response.
>>
>> Traditionally Squid has used it for forwarding loop detection and
>> prevention. However, it also carries the feature of relaying
>>
>> This header is becoming important to relay promises end-to-end security
>> in the presence of HTTPS interception I would like your opinions on
>> removing the current "via off" configuration setting behaviour from
>> Squid. It is way too blunt a tool for the HTTP protocol
>> permitted/forbidden things regarding this header.
> I am opposed to removing the functionality to delete, adjust, or not
> emit any header, including Via.

NP: this is not removing ability. The header mangling directives offer
these same semantics in a much more flexible and targetable way. I am
only proposing removing or updating the sledgehammer directive.

> There are many good reasons for sending correct Via, of course, but they
> do not trump the necessity to shape the headers specially under special
> circumstances. If we do not give admins official tools to sculpture
> outgoing traffic, they will waste their and our time discussing lack of
> those tools and adding those tools unofficially.
>
> Let's focus on implementing correct, smart, and compliant proxy while
> allowing an admin to adjust Squid behavior under special circumstances,
> at their own risk.
>
> If you want to add a second "--enable really bad HTTP violations"
> ./configure option and honor "via off" only if that option is enabled,
> that may be an acceptable compromise. However, I question whether
> deleting Via is really much worse than many other HTTP violations we allow.

It's about on par with ignore-private, ignore-auth, ignore_expect_100
and a few others regarding impact when things do go wrong. Practical
risk is unknowable because it is the mechanism for detection and the
amount of network breakage is completely unrecorded as a result of
popular eliding.

> Now to the actual "upgrade" part of your proposal:
>
>> So my proposal for now is to modify the "via" config option to toggle
>> whether or not Squid compacts a series of semantically identical Via
>> entries down to one opaque blob or not. Hops are considered identical if
>> their protocol name and version are identical.
>>
>> For example:
>>
>> Via: 1.0 foo, 1.1 internal.example.com, 1.1 localhost.example.com
>> becomes
>> Via: 1.0 foo, 1.1 example.com
>>
>> Opinions?
> Is that your definition of semantical entry equivalence or an HTTP
> definition? Either way is fine, of course, but the difference affects
> what configuration knobs this feature will need.

HTTPbis definition. "A proxy or gateway /MAY/ combine an ordered
subsequence of Via header field entries into a single such entry if the
entries have identical received-protocol values."

I'm thinking we avoid that by default since it will break
forwarding-loop detection just as badly a dropping the header would.
However "via compact" or similar would be compliant instead of "via
off". As would "via transparent" with identical meaning as
"forwarded_for transparent" for use on internal hierarchy proxies.

> Is there a specific use case that you are trying to accommodate here or
> are we discussing a feature that seems useful in general but is not
> currently requested (and so the actual future use cases may require a
> different functionality)?

I'm trying to improve HTTP compliance while retaining support for all
the current use cases. IMO in a lot of cases being properly compliant
will meet the need better than the current code.

Amos
Received on Sun Apr 21 2013 - 03:18:13 MDT