On 09/07/2016 01:56 AM, Matus UHLAR - fantomas wrote:
> and how is this done? Which system or library call does drop connection to
> send a RST immediately?
This is not a squid-users question, but Squid calls comm_reset_close()
(quoted below) to reset the connection. That function uses zero
SO_LI
On 05.09.16 23:32, Omid Kosari wrote:
Filed a bug report http://bugs.squid-cache.org/show_bug.cgi?id=4585
On 09/06/2016 08:36 AM, Matus UHLAR - fantomas wrote:
I wonder if this is doable at all.
On 06.09.16 12:02, Alex Rousskov wrote:
Yes, and Squid supports it in other contexts.
and how
On 09/06/2016 08:36 AM, Matus UHLAR - fantomas wrote:
> On 05.09.16 23:32, Omid Kosari wrote:
>> Filed a bug report http://bugs.squid-cache.org/show_bug.cgi?id=4585
>
> I wonder if this is doable at all.
Yes, and Squid supports it in other contexts.
> Does any tcp stack allow sending reset AFTE
On 05.09.16 23:32, Omid Kosari wrote:
Filed a bug report http://bugs.squid-cache.org/show_bug.cgi?id=4585
I wonder if this is doable at all.
when squid accepts a connnection, it only can close it without noticing.
Does any tcp stack allow sending reset AFTER the connection has been
opened?
-
Filed a bug report http://bugs.squid-cache.org/show_bug.cgi?id=4585
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/TCP-RESET-non-http-requests-on-port-80-tp4679102p4679361.html
Sent from the Squid - Users mailing list archive at Nabble.com.
_
On 08/29/2016 07:40 AM, Omid Kosari wrote:
> config:
> http_reply_access deny all
> deny_info TCP_RESET all
>
> =
> test type:
> telnet 123.com 80
> sgsdgsdgsdgsdg
>
> RESULT:
> HTTP/1.1 403 Forbidden
> Server: squid
> Mime-Version: 1.0
> Date: Mon, 29 Aug 2016 13:30:47 GMT
> Content-Type:
Alex Rousskov wrote
> On 08/28/2016 03:10 AM, Omid Kosari wrote:
>> Alex Rousskov wrote
>>> I understand that it works for regular requests. Does it also work
>>> (i.e.,
>>> does Squid reset the connection) when handling a non-HTTP request on
>>> port 80?
>
>> No , when the request is non-HTTP it
On 08/28/2016 03:10 AM, Omid Kosari wrote:
> Alex Rousskov wrote
>> I understand that it works for regular requests. Does it also work (i.e.,
>> does Squid reset the connection) when handling a non-HTTP request on port 80?
> No , when the request is non-HTTP it does not reset the connection .
Gre
Alex Rousskov wrote
> I understand that it works for regular requests. Does it also work (i.e.,
> does Squid
> reset the connection) when handling a non-HTTP request on port 80?
No , when the request is non-HTTP it does not reset the connection .
Here is my test results . i would test with 123.
On 08/27/2016 05:44 AM, Omid Kosari wrote:
> Alex Rousskov wrote
>> I recommend starting with something like this:
>>
>> http_reply_access deny all
>> deny_info TCP_RESET all
>>
>> Does that reset all connections to Squid (after Squid fetches the reply)?
>
> Thanks for reply .
>
> As i mentio
Alex Rousskov wrote
> I recommend starting with something like this:
>
> http_reply_access deny all
> deny_info TCP_RESET all
>
> Does that reset all connections to Squid (after Squid fetches the reply)?
Thanks for reply .
As i mention before the deny_info works in other configs for example
On 08/26/2016 08:42 AM, Omid Kosari wrote:
> Alex Rousskov wrote
>> I do not know why deny_info does not work in your tests.
> Should i give up ?
I cannot answer that question, but if you decide to keep going, then I
am sure that somebody can figure out why deny_info does not work for
you. You ma
Alex Rousskov wrote
> I do not know why deny_info does not work
> in your tests.
Should i give up ?
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/TCP-RESET-non-http-requests-on-port-80-tp4679102p4679207.html
Sent from the Squid - Users mailing list archive
On 08/24/2016 12:24 PM, Omid Kosari wrote:
> Alex Rousskov wrote
>> Thus, the existing implementation should cover non-HTTP
>> requests on port 80 (or 3128). If it does not, it is a bug. We should
>> polish the documentation to make this clear.
> The problem is not squid itself . The problem is i
Alex Rousskov wrote
> Thus, the existing implementation should cover non-HTTP
> requests on port 80 (or 3128). If it does not, it is a bug. We should
> polish the documentation to make this clear.
The problem is not squid itself . The problem is in some situations for
example DOS(with malformed re
On 08/24/2016 07:54 AM, Amos Jeffries wrote:
> on_unsupported_protocol will need patching to be applied when HTTP
> parser detects unsupported protocol on port 80 (or 3128).
on_unsupported_protocol determines (among other things) Squid behavior
when encountering a strange (i.e., probably non-HTTP)
acl status_400 http_status 400
deny_info TCP_RESET status_400
http_reply_access deny status_400
still send headers . just the 400 changed to 403
HTTP/1.1 403 Forbidden
Server: squid
Mime-Version: 1.0
Date: Wed, 24 Aug 2016 14:11:35 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 5
X-C
On 25/08/2016 12:39 a.m., Omid Kosari wrote:
> This config works for dstdomain acl type
>
> acl test dstdomain 123.com
> deny_info TCP_RESET test
> adapted_http_access deny test
>
>
> but it is not what i want . I want
>
> acl status_400 http_status 400
> deny_info TCP_RESET status_400
> adapt
This config works for dstdomain acl type
acl test dstdomain 123.com
deny_info TCP_RESET test
adapted_http_access deny test
but it is not what i want . I want
acl status_400 http_status 400
deny_info TCP_RESET status_400
adapted_http_access deny status_400
OR
acl HTTP proto HTTP
acl PORT_80
19 matches
Mail list logo