[squid-users] squidGuard: redirect to squid-internal URLs no longer working with 3.5?

[Amos Jeffries]

On 15/03/2016 9:25 p.m., Silamael wrote:
> On 03/15/2016 12:10 AM, Amos Jeffries wrote:
>> On 15/03/2016 2:22 a.m., Silamael wrote:
>>>
>>> On 03/14/2016 02:16 PM, Kinkie wrote:
>>>> Hi,
>>>>   .. has it ever? internal:// doesn't seem like a recognized protocol to me.
>>> It worked till the update to Squid 3.5.
>>>
>>
>> It should not have. That was a bug.
>>
>> The correct syntax for 'internal:' URI looks like:
>>
>>   internal://$visible_hostname:3128/squid-internal-static/...
> 
> Sorry, I don't get it. Formerly we had
> internal://squid-internal-static/error-access-denied and this resulted
> in the ERR_ACCESS_DENIED page being delivered to the client.
> Now you say this has been wrong all the time and the correct path would
> be internal://$visible_hostname:3128/squid-internal-static/...

Yes.

> So, if i try this, i get a 404 response and the ERR_INVALID_REQ page.

Okay. That is the correct behaviour for this situation.
Squid does not normally load anything at the
/squid-internal-static/error-access-denied path.

A second bug / undefined behaviour that got fixed in 3.5 was incorrect
HTTP status codes being delivered on cachemgr and internal responses. It
now returns 404 Not Found when URL internal URL does not point at an
object, not "access denied" - because access wasn't denied, the file was
not found.

The /squid-internal-static/* objects to be loaded are configured in the
squid /etc/squid/mime.conf configuration file. (though some OS distros
move it out of /etc/squid for some reason).

However, that would just make the response a 200 OK with the internal
object as the payload. If you want to retain 403 you need to block the
re-written URL from being serviced by Squid:

 acl SG_deny urlpath_regex ^/squid-internal-static/error-access-denied$
 adapted_http_access deny SG_deny

(If that dont work you can use miss_access instead)


> With debugging I can see that there is a request like
> GET ://127.0.0.1:3128/squid-internal-static/error-access-denied
> This is indeed an invalid request...

Nod. Though the internal ID being used is correct, so its only the
output display and upstream messages which are broken. I'm looking into
that now, but the fix wont change anything relating to your actual
problem. You will still need to use the above config settings to trigger
a 403.


> If I use http:// instead of internal:// the whole request is forwarded
> to the upstream cache peer and again replied with ERR_INVALID_REQ...
> With
> internal://$visible_hostname:3128/squid-internal-static/error-access-denied
> the response is a 400 Bad Request with ERR_UNSUP_REQ.
> According to debugging here again the internal schema is not passed
> along when building the GET request.
> 
> BTW, the old URL I used worked for years!

The problem with relying on undefined behaviour is that it can work for
a long time then disappear without warning.

What I think was going on previously was the parser handling the
URL-rewriter output accepted the URL with 'squid-internal-static' as
hostname. When Squid got to the upstream forwarding stage the check for
internal status did a sub-string check and (wrongly) found
"/squid-internal-". So decided to handle it as internal. But the
internal-server logics could not find any object and (wrongly) generated
a 403 error page.

So a chain of at least 2 bugs being relied on to produce a 403 Access
Denied, when it should not have. We have now fixed those bugs, so what
you had relying on them goes splat.

Amos