Uncaught SyntaxError: missing { before class body" in file index.js:109:12403.
Closing due to lack of information. Please feel free to reopen if you can reproduce the problem with the requested debug settings.
Building Privoxy using wolfssl
The wolfSSL issue has been fixed upstream a while ago.
deny-access causes network errors when a destination address or network is specified
This should finally be fixed in git master. Thanks again for the report.
Thanks for your reply. I’ve just found some x64 builds of older versions at Github: https://github.com/ssrlive/privoxy/releases Perhaps that’s a start point. I’ve contacted the developer but it seems that he doesn’t want to keep doing this for new versions.
On Sat, Mar 7, 2026 at 4:10 PM Chungalin wrote: [feature-requests:#609] Windows x64 build Why is there only a x86 build for Windows instead of x64? Because I read https://cygwin.com/faq.html#faq.programming.64bitporting and decided I didn't know enough to even think about doing an x64 build. I know that x86 version can run in both systems, but being now x64 the predominant architecture, it seems that it’s time to at least offer both builds. Are you volunteering to do the builds? Regards, Lee
Windows x64 build
Feature request: Prefer EC Certificates for HTTPS Inspection
I've committed support for an elliptic-curve-keys directive that is enabled by default. Thanks again for the reminder.
It is impossible to disable redirect if the protocol is wss
Thanks for the report. Please provide a log excerpt that shows the problem.
It is impossible to disable redirect if the protocol is wss
Thanks!
fix detection and use of pcre2.h from a subdirectory
Thanks for the report and patch. Applied and pushed after changing configure.ac to configure.in.
fix detection and use of pcre2.h from a subdirectory
Thanks for the report. Please create a new bug report with a patch in git-format-patch format against git master if possible.
Should I create a new bug, or is the report above sufficient?
Hi, I've hit several pcre2 related issues when building privoxy 4.0.0 on Solaris (where the header lives in a sub-directory). The configure script for pcre2/pcre2.h has the following issues: * the inner header check (for pcre2/pcre2.h) is missing the PCRE2_CODE_UNIT_WIDTH define and hence always fails. * the same check doesn't define HAVE_PCRE2 on success. Here is the patch for the necessary changes: --- privoxy-4.0.0-stable/configure.in +++ privoxy-4.0.0-stable/configure.in @@ -887,8 +887,8 @@ AC_CHECK_LIB(pcre2-8,...
Just launch privoxy.exe as administrator or best set it up to always launch as administrator (right click privoxy.exe -> properties -> Compatibility tab -> Run this program as administrator). Works for me.
Just launch privoxy.exe as administrator or best set it up to always launch as administrator (right click privoxy.exe -> properties -> Compatibility tab -> Run this program as administrator
Privoxy for mipsel devices
Thanks for the suggestion but unfortunately it looks like no packager is using mipsel. In the mean time, building from source should work: https://www.privoxy.org/user-manual/installation.html#INSTALLATION-SOURCE
Privoxy for mipsel devices
ca-directory keyword error
yes! closed / fixed now
I remember being able to close tickets on sourceforge. I seem to have lost that ability :( Does it work now? I checked the user permissions and you are part of the "Developer" group which has "update", "admin" and "create" permissions (all the permissions available) but "Developers" are also part of the "Member" group which had all the permissions removed. I changed the "Member" permissions to "update", "admin" and "create" .
On Sat, Apr 5, 2025 at 2:34 PM Lee wrote: I just uploaded a Windows 4.0.0-1 release that supports https-inspection That should resolve the problem I remember being able to close tickets on sourceforge. I seem to have lost that ability :( Lee
I just uploaded a Windows 4.0.0-1 release that supports https-inspection That should resolve the problem
Building with MbedTLS for Windows sounds good to me. Having said that, OpenSSL 3.x is licensed under the Apache License v2 so redistribution is no longer a no-no as the license is compatible with the GPLv3 and the Privoxy code is licensed GPLv2 or later which includes GPLv3. The documentation could probable by more clear about this.
On Thu, Apr 3, 2025 at 7:55 AM Jim Dunn wrote: Oh no... YOU ARE RIGHT... I guess my v3.x.x was "compiled with FEATURE_HTTPS_INSPECTION"... but I didn't do it. Where can I find the v4.0.0 that HAS that FEATURE_HTTPS_INSPECTION based in ??? I can put one up on sourceforge for you (and everyone else) or you can follow the instructions at https://www.privoxy.org/user-manual/installation.html#WINBUILD-CYGWIN and build it yourself. Fabian - I never figured out how to build wolfssl and openssl is still...
Oh no... YOU ARE RIGHT... I guess my v3.x.x was "compiled with FEATURE_HTTPS_INSPECTION"... but I didn't do it. Where can I find the v4.0.0 that HAS that FEATURE_HTTPS_INSPECTION based in ???
ca-directory keyword error
What exactly is the error message you get? Are you sure your Privoxy version has been compiled with FEATURE_HTTPS_INSPECTION? You can check at: http://config.privoxy.org/show-status
ca-directory keyword error
Uncaught SyntaxError: missing { before class body" in file index.js:109:12403.
Thanks for the report. Please reproduce the problem with the debug settings recommended at: https://www.privoxy.org/user-manual/contact.html and provide a log file. I'm wondering if the the index.js file gets delivered with the correct content type and if the server-header-tagger{content-type} is enabled.
Uncaught SyntaxError: missing { before class body" in file index.js:109:12403.
I have experience of such communication with owners (or their representatives) of sites, negative. The answer will be: everything is fine with us, the problem is on your side. And explaining how my Internet access is arranged will cause even more misunderstanding. It seems to me that we need to move towards forging the browser fingerprint via "cipher-list", so far this has not worked, the fingerprint is still different. But most likely, this option is not for this, but I would like to have something...
When scrolling the page, pictures disappear (chizhik.club)
Thanks for the report. I was able to reproduce the problem but it's not obvious to me that it's Privoxy's fault as the problem is reproducible with filters disabled. The site tries to prevent accesses by bots and it's possible that app.chizhik.club doesn't like Privoxy's TLS connections. You could try asking the site operators if they have any ideas what's causing the problem.
When scrolling the page, pictures disappear
3.0.34 segfaults Editing actions
Thanks. I was able to reproduce the problem with privoxy-3.0.34_1 and confirmed that it is no longer reproducible with 4.0.0 due to e32d03e0858.
The original setup no longer exists. But the build configuration does not have an option for that, so it probably was the default - which seems to disabled. I'm currently running FreeBSD 13.4 with the privoxy-3.0.34_1 package compiled by the FreeBSD project. It does have FEATURE_EXTERNAL_FILTERS disabled and it does crash.
Thanks. Please excuse the delayed response. I agree that this is probably a duplicate of SF bug #940 which should be fixed in Privoxy 4.0.0 which is supposed to be released in a couple of days. Can you confirm that FEATURE_EXTERNAL_FILTERS is enabled?
Thanks. Please excuse the delayed response. I believe that this is a duplicate of SF bug #940 which should be fixed in Privoxy 4.0.0 which is supposed to be released in a couple of days. Can you confirm that FEATURE_EXTERNAL_FILTERS is enabled?
Happens with the user.action that only got edited via web interface, but also happens with the match-all.action, which is very simple: { \ +change-x-forwarded-for{block} \ +client-header-tagger{css-requests} \ +client-header-tagger{image-requests} \ +hide-from-header{block} \ +set-image-blocker{pattern} \ } With the match-all, it segfaults like this: (gdb) bt #0 0x00000008465507b4 in strlen () from /lib/libc.so.7 #1 0x00000008465bde72 in strdup () from /lib/libc.so.7 #2 0x000000000023fe9c in map...
3.0.34 segfaults Editing actions
Thanks for the report. Does this happen for all action files or only one specific one? Did you modify the action file(s) that trigger the segfault?
3.0.34 segfaults Editing actions
Thank you! Regarding i.kommersant.ru, geoblocking is possible, but not sure, because... curl works for me: curl -v --head https://i.kommersant.ru/ * Host i.kommersant.ru:443 was resolved. * IPv6: (none) * IPv4: 185.147.37.72 * Trying 185.147.37.72:443... * Connected to i.kommersant.ru (185.147.37.72) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (IN), TLS handshake, Server hello (2):...
I can reproduce the issue that the comments don't load on https://www.kommersant.ru/ but on my systems the problem seems to be that connections to i.kommersant.ru already fail before the TLS handshake: fk@elektrobier ~ $curl -v --head https://i.kommersant.ru/ * Host i.kommersant.ru:443 was resolved. * IPv6: (none) * IPv4: 185.147.37.72 * Trying 185.147.37.72:443... * connect to 185.147.37.72 port 443 from 95.211.138.7 port 63777 failed: Operation timed out * Failed to connect to i.kommersant.ru port...
If it's not too much trouble for you, please spread the word. Regarding i.kommersant.ru, if you open this link "https://www.kommersant.ru/doc/6821399#comments" and click the blue button under the message, user comments should load, but instead you will see that message in the log, and the comments will not load.
If it's not too much trouble for you, please spread the word. Regarding i.kommersant.ru, if you open this link "https://www.kommersant.ru/doc/6821399" and click the blue button under the message, user comments should load, but instead you will see that message in the log, and the comments will not load.
i.kommersant.ru remains unreachable for me but I can reproduce the problem with https://traxxas.com/ with both Privoxy and curl linked against wolfSSL 5.7. I consider this a wolfSSL bug worth reporting upstream. Do you want to do it or should I?
WolfSSL 5.7 i.kommersant.ru works when you click the button (if there is one) under the news. The site that definitely does not work for me with WolfSSL: traxxas.com, instead of opening it I see the message: Server certificate verification failed Privoxy was unable to securely connect to the destination server. Reason: received alert fatal error In the log there is a message "Error: X509 certificate verification for traxxas.com failed with error -313: received alert fatal error"
Which WolfSSL version do you use? When I try i.kommersant.ru it doesn't seem to respond to requests to port 443 so it doesn't work with either OpenSSL or WolfSSL for me.
Fix build on macOS
Thanks a lot for the patch. Pushed to git master.