Re: [RFC] Upgrade for via cofnig setting

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.

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.

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.

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)?

Thank you,

Alex.
Received on Sat Apr 20 2013 - 16:20:34 MDT