On 11/03/18 11:36, Eduard Bagdasaryan wrote: > Hi Squid developers, > > > I need your competent help with the following issue. > > While working on some public key generation issues I noticed that Squid > does not decode percent-encoded URLs (at least before creating public > keys). While trying to understand whether it is correct, I > searched RFC7230 family for proxy-related MUST requirements but > unfortunately did not find them. Another RFC3986 p. 6.2.2.2. describes > 'percent-encoding normalization' of unreserved characters, but this is > not a 'MUST' requirement. So, at first glance, Squid does not violate > RFCs in this case. However, the fact that two equivalent URLs (with and > w/o percent encoding) are treated differently may cause some > confusion: for example, a 'DELETE' for such equivalent URL would fail. > > So my questions are: > > * are there any percent-encoding requirements for proxies? >
AFAIK there are none specific to proxies. The client and server requirements should be used on the relevant received or sent URLs. IMO the decode should be done in URL::parse() method, and a re-encode should be done in the getter methods as relevant for each URL section (they are different, based on the different invalid-char sets). FYI: When attempting to do that I was overridden by the QA requirement that URLs "must not be changed" by Squid. The natural side effect is the caching problem you describe, along with a DoS vulnerability which apparently nobody in the "real world" cares about. > * does Squid violate them? > Squid complies with RFC 1738 (not RFC 3986) currently. Cheers Amos _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
