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

squid-dev mailing list

Reply via email to