On Wednesday, November 4, 2020, 3:27:25 AM GMT+1, Alex Rousskov
wrote:
> https://bugs.squid-cache.org/show_bug.cgi?id=5084
Hi,
I added a comment to that bug report.
I cannot reproduce the problem anymore, at least not with the latest version of
Squid 5.
Thanks,
Vieri
On 10/18/20 6:07 PM, Vieri wrote:
> Please let me know if I should add something to the bug report
If you can retest with the triage patch attached to the bug report,
please do so an post new error messages produced by the patch (if any).
You can post them to the bug report (preferred) or here.
Hi Vieri,
I attached a patch to bug5084 which may help us to debug the issue:
https://bugs.squid-cache.org/attachment.cgi?id=3772
The patch is for squid-v5 and produces debug messages at debug level 1.
Regards,
Christos
On 17/10/20 11:36 μ.μ., Alex Rousskov wrote:
On 10/16/20 11:58 A
On 19/10/20 11:07 am, Vieri wrote:
>
> On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov wrote:
>
>> or due to some TLS error.
>> I filed bug #5084
>
> Hi again,
>
> Thanks for opening a bug report.
>
> I don't want to add anything there myself because I wouldn't want to confu
On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov
wrote:
> or due to some TLS error.
> I filed bug #5084
Hi again,
Thanks for opening a bug report.
I don't want to add anything there myself because I wouldn't want to confuse
whoever might take this issue into account, but I
On 10/16/20 11:58 AM, Vieri wrote:
> I pinpointed one particular request that's failing:
>
> 2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745)
> clientAccessCheckDone: The request GET
> https://ed1lncb62601.webex.com/direct?type=websocket&dtype=binary&rand=1602860196950&uuidtag=G7
On 17/10/20 3:07 am, Vieri wrote:
> Hi,
>
> I think I found something in the cache.log I posted before.
>
> sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_3
> ...
> sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_2
>
> It seems that Squid sometimes connects to the remote HTTP server with
On Friday, October 16, 2020, 4:48:55 PM GMT+2, Alex Rousskov
wrote:
> tcp_outgoing_address.
OK, I fixed the "local" address issue, but I'm still seeing the same behavior.
I pinpointed one particular request that's failing:
2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745)
cl
On 10/16/20 10:41 AM, Vieri wrote:
> BTW how does Squid decide which IP address to use for "local" here below?
>
> sendRequest: HTTP Server conn* local=
By default, Squid does not make that decision. The OS does it for Squid.
You can try to force Squid to bind to a specific source address for
out
On 10/16/20 3:35 AM, Vieri wrote:
> squid-5.0.4-20200825-rf4ade365f/src/cf.data.pre contains:
> Usage: http_upgrade_request_protocols allow|deny [!]acl ...
>
> The required "protocol" parameter is either an all-caps word OTHER or
> an
> explicit protocol name (e.g. "WebSo
On Thursday, October 15, 2020, 5:28:03 PM GMT+2, Alex Rousskov
wrote:
>> In other words, I do not need to be specific with
>> 'http_upgrade_request_protocols WebSocket allow all' unless I want
>> to, right?
>
> Just in case somebody else starts copy-pasting the above rule into their
> configu
On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov
wrote:
> You should probably follow up with Gentoo folks responsible for this Squid
> customization.
Squid 5 now builds and installs perfectly on Gentoo Linux with a few custom
changes to the distro's package installation script.
On 10/15/20 10:08 AM, Vieri wrote:
> On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov wrote:
>> You should probably follow up with Gentoo folks responsible for this Squid
>> customization.
> Squid 5 now builds and installs perfectly on Gentoo Linux with a few
> custom changes to th
On Tuesday, October 13, 2020, 3:55:56 PM GMT+2, Alex Rousskov
wrote:
> The beginning of the above log appears to show some unofficial bootstrapping
> steps.
Yes, I was looking into this today and I saw that the actual difference between
a manual build and a Gentoo Linux build is with the f
On 10/13/20 11:21 AM, Vieri wrote:
> I saw that the actual difference between a manual build and a Gentoo Linux
> build is with the following:
> 1) the build fails as mentioned earlier in this thread when running
> Gentoo-specific "configure" scripts. Bootstrapping makes no real
> difference.
>
On 10/12/20 7:35 PM, Vieri wrote:
> I'm compiling on a Gentoo Linux system the tarball taken from
> http://www.squid-cache.org/Versions/v5/squid-5.0.4.tar.gz.
> The build log (failed) is here (notice the call to make -j1):
> https://drive.google.com/file/d/1no0uV3Ti1ILZavAaiOyFIY9W0eLRv87q/view?
Just a quick test and question.
If I manually create the tests subdirs and run make then I get an error such as:
/bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall
-Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -pipe
-D_REENTRANT -O2 -pipe -
On 10/11/20 11:03 AM, Vieri wrote:
> If I manually create the tests subdirs and run make then I get an error such
> as:
>
> /bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall
> -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual
> -pipe -D_REENTRA
On 10/10/20 1:13 PM, Vieri wrote:
> I'm also getting this other file that can't be copied:
>
> cp ../../src/tests/stub_debug.cc tests/stub_debug.cc
> cp: cannot create regular file 'tests/stub_debug.cc': No such file or
> directory
> make[3]: *** [Makefile:1490: tests/stub_debug.cc] Error 1
>
>
On 11/10/20 6:13 am, Vieri wrote:
> I'm also getting this other file that can't be copied:
>
> cp ../../src/tests/stub_debug.cc tests/stub_debug.cc
> cp: cannot create regular file 'tests/stub_debug.cc': No such file or
> directory
> make[3]: *** [Makefile:1490: tests/stub_debug.cc] Error 1
>
>
On Friday, October 9, 2020, 3:28:01 AM GMT+2, Amos Jeffries
wrote:
> I advise explicitly using -j1 for the workaround build.
Well, I'm running with -j1, but I'm still getting the same error message.
Here's a snippet of the build log:
make -j1
Making all in compat
make[1]: Entering director
On 9/10/20 11:56 am, Vieri wrote:
>> As a workaround, try sequential build ("make" instead of "make -j...")
>
> I removed -j, but I'm still getting a similar error:
>
Not just similar. The same one.
FYI, some make do parallel by default. I advise explicitly using -j1 for
the workaround build. T
On 10/8/20 5:11 AM, Vieri wrote:
> OK, so I'm now trying to compile Squid 5 instead of backporting to V 4, but
> I'm getting this silly error:
> cp ../../src/tests/stub_fd.cc tests/stub_fd.cc
> cp: cannot create regular file 'tests/stub_fd.cc': No such file or directory
> make[3]: *** [Makefile:1
On 10/7/20 9:29 AM, Vieri wrote:
>> To allow WebSocket tunnels, you need http_upgrade_request_protocols
>> available since v5.0.4
> What would the easiest way be to allow websockets through in v. 4?
Backport (the essential parts of) v5 changes to v4.
> That is, for trusted domains, allow a dir
On 8/10/20 2:29 am, Vieri wrote:
>> To allow WebSocket tunnels, you need http_upgrade_request_protocols
>> available since v5.0.4
>
> Thanks for the info.
> My distro does not include v. 5 yet as it's still beta, although I could try
> compiling it.
>
> Just a thought though. What would the eas
On 10/7/20 4:08 AM, Vieri wrote:
> I'd like to allow websockets from specific domains through Squid in
> intercept sslbump mode.
> I am obviously not using on_unsupported_protocol properly.
WebSocket handshake looks like HTTP so on_unsupported_protocol is not
applicable to the WebSocket protocol
26 matches
Mail list logo
