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.
