Re: [RFC] Upgrade for via cofnig setting

On 04/20/2013 09:18 PM, Amos Jeffries wrote:
> 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.

I agree that flexible header mangling features are better than
all-or-nothing "via on/off" if we have to pick one or the other.

If, after "via off" is removed, the existing header mangling code can
delete Vary completely and will not be prohibited from Vary manipulation
in the future, then we can remove "via off". Please test whether Via
deletion via "header_access" works on both client and server side after
removing "via off".

>> 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."

OK. Are there more related MAYs or SHOULDs in HTTPbis? For example, I
know RFC 2616 has this restriction:

> Applications SHOULD NOT combine multiple entries unless they are all
> under the same organizational control and the hosts have already been
> replaced by pseudonyms.

Is that or similar restriction still in HTTPbis?

> I'm thinking we avoid that by default since it will break
> forwarding-loop detection just as badly a dropping the header would.

Yes, doing that by default would be wrong, on many levels, including
violating the above quoted RFC 2616 SHOULD NOT.

> 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.

It would be difficult to implement "via compact" correctly without
violating the above SHOULD NOT because Squid does not know which of the
same-protocol entries are pseudonyms under the same organizational
control. Either Squid will violate that SHOULD NOT or we will have to
add complex options to detect same-organization pseudonyms.

>> 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.

I am not sure I understand your motivation here because implementing
MAYs has no effect on compliance. I do not think we should try to
implement MAYs that are difficult to implement correctly, that do not
improve anything in general, and that are not requested by admins. All
of the three criteria apply to "MAY collapse" AFAICT from RFC 2616 point
of view. Perhaps HTTPbis makes the correct implementation easier?

Cheers,

Alex.
Received on Mon Apr 22 2013 - 16:20:02 MDT