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.
