ProxHTTPSProxyMII: Reloaded
|
Dec. 07, 2018, 03:40 PM
Post: #301
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
SOLVED!
I've made some progress, after my "random thought" last night... Using the Dev Tools panel in Firefox, I loaded https://www.google.com. Here are the request headers and the Privoxy results log: Code: Host: www.google.com Note that none of the three filters had any matches. I then made exactly the same request again, with one alteration to the headers: Code: Host: www.google.com Now we see that two of the filters DID have matches, and the filtering worked! What changed? This "Decompression successful. Old size: 69335, new size: 219348" was not done in the first request, so Privoxy was trying to filter compressed content. Either deflate or br. With that in mind, I checked the options for Firefox, to see if it allows configurations of what encodings it supports, and found under about:config this option: "network.http.accept-encoding.secure;gzip, deflate, br". I removed "br" from the end, and now my HTTPS filters work!! So I guess that Privoxy simply does not support Brotli encoding. |
|||
The following 1 user says Thank You to Quaraxkad for this post: referrer |
Dec. 17, 2018, 08:08 PM
Post: #302
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
Quote:Is it possible that Firefox and Chrome are requesting pages in a compression/encoding/whatever format that Privoxy can't understand?"prevent-compression" in privoxy used? |
|||
The following 1 user says Thank You to vlad_s for this post: referrer |
Dec. 18, 2018, 12:16 AM
Post: #303
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded | |||
Dec. 18, 2018, 12:41 AM
(This post was last modified: Dec. 18, 2018 12:52 AM by referrer.)
Post: #304
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
'prevent-compression' can do the job.
Code: 8.5.30. prevent-compression Code: CLIENT-HEADER-FILTER: NO-BR Remove Accept-Encoding Brotli. |
|||
Dec. 18, 2018, 12:52 AM
Post: #305
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
Ahh, I see. I have all of the default actions and filters disabled, I wasn't aware of that one. As soon as I recognized the problem, my alternative solution if Firefox didn't have that "network.http.accept-encoding.secure" option was going to be a client-header-filter to remove Brotli.
|
|||
Dec. 19, 2018, 02:36 AM
Post: #306
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
I hope I'm not the only one having this issue. Its nothing breaking fortunately, just very disruptive. After awhile of browsing, there will be moments where loading a site will temporarily stop, as if it hit a snag or something. Trying to reload or access any other sight will yield the same result, the browser is trying to load it but is unable to as if your internet connection was being disrupted. However, once you click abort all active connections via proxomitron, any website that is stuck loading will suddenly snap out of it and will proceed to finish.
Its as if you are giving proxomitron a defibrillation when it stops as you hit the abort connections button. This is something that has to be done almost every couple of minutes of regular web browsing, and as I'm sure you can imagine it gets pretty frustrating. Is this a known problem? I hope I was clear with my explanation. |
|||
Dec. 19, 2018, 05:13 AM
Post: #307
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
(Dec. 19, 2018 02:36 AM)Hydl Wrote: I hope I'm not the only one having this issue. Its nothing breaking fortunately, just very disruptive. After awhile of browsing, there will be moments where loading a site will temporarily stop, as if it hit a snag or something. Trying to reload or access any other sight will yield the same result, the browser is trying to load it but is unable to as if your internet connection was being disrupted. However, once you click abort all active connections via proxomitron, any website that is stuck loading will suddenly snap out of it and will proceed to finish. Have this issue too. It seems sometimes proxhttpsproxy didn't close the connection. In proxifier connections window I find many connections keep by proxhttpsproxy. Proxomitron's abort button cannot close all of them. When this happens I always use the 'reload' button in 'proxhttpsproxy Launcher'. |
|||
Dec. 19, 2018, 12:41 PM
Post: #308
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
What Proxomitron version are you using? Do you have a multiple-core machine? Even the latest one Scott released contains a few multithreading bugs which would not have been noticeable on the single-core machines widely used in his time. You can try setting Proxomitron's affinity to a single core (right-click in Task Manager to select Set Affinity) and see if the problem disappears or reduces in frequency.
You may also want to give Proxomitron Reborn a try, either behind ProxHTTPSProxy or using its own SSL filtering capabilities. |
|||
Dec. 20, 2018, 01:08 AM
(This post was last modified: Dec. 20, 2018 03:06 AM by Hydl.)
Post: #309
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
Hello Amy. I am using version Naoko 4.5 (2003-6-1). I do have a multi core CPU and after setting both Proxomitron and ProxHTTPSProxyMII to use one thread only, the problem as you predicted reduces in frequency. I am able to browse a lot more but will eventually need to abort all connections.
I think its terrific that you are developing Proxomitron Reborn, and I wish you all the best with it. Though unfortunately the problem persists when using it. Again its not as frequent, but it still happens. |
|||
Dec. 22, 2018, 09:54 AM
Post: #310
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
(Dec. 18, 2018 12:41 AM)referrer Wrote: Privoxy's TODO said the 'prevent-compression' action will be removed.It is a pity that they cut such functionality. In general, with the dominance of https-sites, developers should think about their wonderful proxy, which will lose more and more unique opportunities. |
|||
Dec. 23, 2018, 09:25 PM
(This post was last modified: Dec. 23, 2018 09:26 PM by vlad_s.)
Post: #311
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
Error log:
Code: python3[3481]: 127.0.0.1 - - [24/Dec/2018 00:13:48] code 400, message Bad request syntax ('CNT 1 CON 260') Code: https://coms-bwxszt8x.cont.ws/socket.io/?EIO=3&transport=websocket |
|||
Dec. 24, 2018, 04:47 AM
Post: #312
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
^ That's MSNP, not HTTP. No wonder it's confused. Not everything that establishes an SSL tunnel through an HTTP proxy with CONNECT is going to send HTTP through that tunnel.
|
|||
Jan. 04, 2019, 10:41 PM
(This post was last modified: Jan. 04, 2019 10:42 PM by vlad_s.)
Post: #313
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
After updating Ubuntu 16.04 to Ubuntu 18.04, a message is constantly being sent in the syslog:
Code: ---------------------------------------- |
|||
Jan. 12, 2019, 02:40 PM
(This post was last modified: Jan. 12, 2019 02:43 PM by vlad_s.)
Post: #314
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
I use the decentraleyes option from here. Redirection is done on my own web server (apache) via https. So that there are no unnecessary questions, I'm in [SSL No-Verify]
added it as 192.168.2.1. Everything was fine until the upgrade to Ubuntu 18.04. After the upgrade, I will get an error for my server: Code: 502: HTTPError |
|||
Jan. 12, 2019, 03:10 PM
Post: #315
|
|||
|
|||
RE: ProxHTTPSProxyMII: Reloaded
The problem was in the version urllib3, version 1.22. At 1.20 and the last which is available for me 1.24.1 this error is not present.
|
|||
« Next Oldest | Next Newest »
|