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
