On 17/10/18 10:37 AM, Amos Jeffries wrote:
On 17/10/18 3:15 PM, Amish wrote:
My proposal for would be to add "-n" (nobump) option to deny_info.
If -n is specified then squid will send 307 directly instead of 200.
Case 1)
deny_info http://192.168.1.1/blocked.html denyit
Return with 200 and bump it (existing behaviour)
Case 2)
deny_info 3xx:http://192.168.1.1/blocked.html denyit
Return with 200 and bump it (existing behaviour)
Case 3)
deny_info -n http://192.168.1.1/blocked.html denyit
Return with 307 Temporary Redirect and Location: header
Case 4)
deny_info -n 302:http://192.168.1.1/blocked.html denyit
Return with 302 Found and Location: header.
Case 1 and 2 above applicable only for sslbump cases.
For non-sslbump it already behaves as 3) and 4) above.
This would not change anything for existing users who want existing
behaviour.
But allow people like me to *NOT* bump connection when deny_info is
activated.
IMO the deny_info is very much the wrong place to be making such
decisions. Its purpose is to supply the *content* of the denial message
itself. Nothing about how that message gets delivered.
If anything this would be an additional ssl-bump option on the port line
to say that traffic is not really being ssl-bump'ed despite the presence
of the ssl-bump setting.
If its additional ssl-bump option then it would become a global thing.
If its on deny_info then for some ACLs I can select to bump and for
others not. (i.e. gives finer control)
So think about that - why bother putting "ssl-bump" on the port in the
first place if the behaviour that option enables is not wanted to ever
happen?
I need SSL bump because I am bumping few domains and splicing rest.
But for blocked domains I prefer browser to show "Proxy refused the
connection" instead of SSL error.
Also browsers not respecting code other than 200 or 407 is actually a
browser bug. Hopefully corrected in future someday.
May be browsers will start supporting 302/307 Location header someday,
for CONNECT requests too?
(ofcourse I am not RFC expert so I may be completely wrong to interpret it)
In any case thank you for your responses. I have more clarity now.
Regards,
Amish.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
