Re: format strings in deny_info?

tis 2003-06-03 klockan 16.01 skrev Gerard Eviston:

> Thanks Henrik. I've attached a slightly modified patch that escapes only the
> substituted data with rfc1738_escape_part(). I understand now why
> rfc1738_escape_part() is needed instead of rfc1738_escape(), but as for
> escaping data before it is inserted in the URL- is this so squid can assume
> that the deny_info url (the part without the format strings) is already
> escaped?

The deny_info URL can be assumed to be a proper URL. If the
administrator specifies a bad URL then so be it, not our job to care.
However, if you want to be able to submit arguments such as the
requested url to this URL then the data in those arguments must be fully
URL escaped

Hypothetical example:

  deny_info http://www.example.com/blocked_access?url=%s

For this to end up as a proper URL the %s needs to be substituted by
urlescape_part() encoded data, ending up with a URL looking something
like the following if the rejected URL is http://www.example.org/test

http://www.example.com/blocked_access?url=http%3a%2f%2fwww%2eexample%2eorg%2fstest

rfc1738_escape_part applies full URL encoding making the result suitable
for a path component or URL escaped argument (: / & = etc escaped).

rfc1738_escape just escapes unsafe characters in the URL. The reserved
characters are left intact.

rfc1738_escape_unescaped just makes sure any unsafe characters in the
url are escaped. Existing %nn escapes are left intact.

What this means is that

While constructing a URL from components, rfc1738_escape_part() should
be used.

If having a URL which one is unsure if it is properly escaped or not
then rfc1738_escape_unescaped() should be used.

The bare rfc1738_escape function is probably not very useful. Cannot
think of any obvious good uses for this one.

-- 
Henrik Nordstrom <hno@marasystems.com>
MARA Systems AB