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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
