Proxomitron Reborn

[JennyH]

(Feb. 14, 2019 04:20 PM)Blazer Wrote:  

(Feb. 10, 2019 02:51 AM)amy Wrote:  Life is busy, but work on 4.6.0.4 continues slowly...

Being a software developer and previous user of The Proxomitron I would be happy to help fix bugs etc.

After all your hard work re-creating the source code it would be a good idea to make it available to the community so that others like myself can participate in its resurrection.

Maybe you you can attach it here.

We don't want to lose the source code a second time.

As a C++ programmer of a few years, I'll agree with Blazer here. I've missed having a working proxomitron. I'd love to take a look at the source to see how I could lend a hand.

[whenever]

(Jan. 05, 2019 04:00 AM)whenever Wrote:  If you turn on debug in the log window, then visit a https site say https://twitter.com, you will see the stylesheet for the dbug view is not applied. If you right click to view the source of that page, you will see the viewsrc.css is inserted via href="http://....." and that's why it's not loaded on a https site. That http:// thing is hardcoded in the program so it needs to be adjusted to automatically adapt to the protocol of the page.

It seems the https backend of the Reborn version handles http requests also, so a temporary workaround is to change the hardcoded href="http://Local.ptron/ViewSrc.css" to href="//Local.ptron:8443/ViewSrc.css" (assuming you have set up 8443 for https) so that the stylesheet will loaded anyway on http or https sites.

For those who don't want to manually patch the file, you can download gsar121.zip from http://tjaberg.com/ , extract gsar.exe from the archive and put it to where your proxo.exe is, and execute:

Code:

gsar -shttp:://Local.ptron/View -r//Local.ptron::8443/View proxo.exe patched_proxo.exe

Edit by JJoe: added space after http://tjaberg.com/
Note by whenever: this patch is not needed any more as version 4.6.0.4 have fixed it.

[DullFace]

ProxomitronReborn_4603R.zip bugs:

Crashes with OpenSSL 1.0.2k, works with 1.0.1l: OpenSSL: FATAL OPENSSL_Uplink(6D857000,08): no OPENSSL_Applink
https://www.upload.ee/files/9803621/Open...k.zip.html

Message log: pressing ctrl disables arrows and pgup/pgdn; next pressing ctrl enables them.
Also Naoko-4.5 2003-6-1 crashed on copying long strings from log (over 1KB crap like Content-Security-Policy; don't have a sample).

4603R and Naoko-4.5 2003-6-1 don't allow downloading files >4GB - they break connection on border filesize & 0xFFFFFFFF (low 32 bits).
Removing 'Content-Length' header helps, but i need it :-D

http://speed.hetzner.de/10GB.bin - Content-Length: 10485760000
(10485760000 & 0xffffffff) - 1234 = 1895824174
Works:

Code:

curl -o test --header "Range: bytes=1895824174-" http://speed.hetzner.de/10GB.bin

Stops after 1234 bytes:

Code:

curl -o test --header "Range: bytes=1895824174-" --proxy 127.0.0.1:2345 http://speed.hetzner.de/10GB.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 8192M    0  1234    0     0   5273      0  18d 20h --:--:--  18d 20h  5273
curl: (18) transfer closed with 8589934592 bytes remaining to read

Please add:

Support launching of multiple independed Proxomitrons (from different dirs: c:\Prox1, c:\Prox2; with their own different configs).

Font setting for filter editor and testing dialogs.

Changing 'Host:' header name case and SNI manipulation for bypassing censorship: remove, replace, append space/dot/semicolon, uppercase

Someting like header filter URL:

Code:

[HTTP headers]
In = FALSE
Out = TRUE
Key = "HOST: make hOsT:"
URL = "$LST(Host_case)"
Replace = "hOsT"

In = FALSE
Out = TRUE
Key = "SNI: remove"
URL = "$LST(SNI_remove)"

In = FALSE
Out = TRUE
Key = "SNI: replace"
URL = "$LST(SNI_google)"
Replace = "www.google.com"

In = FALSE
Out = TRUE
Key = "SNI: add space to host"
URL = "$LST(SNI_space)"
Replace = "\h "

In = FALSE
Out = TRUE
Key = "SNI: upper case"
URL = "$LST(SNI_upper)"
Replace = "$UPPER(\h)"

Or make magic '?' in fist symbol of key and use replace field for header name and value:

Code:

[HTTP headers]
In = FALSE
Out = TRUE
Key = "?Host: make hOsT:"
URL = "$LST(Host_case)"
Replace = "hOsT: \h"

[amy]

Happy Easter! Proxomitron has been Reborn Again -- 4.6.0.4 released!
Changes:
- Use appropriate protocol for local.ptron resources
- Local filtering fixes (related to ports, local.ptron vs localhost/127.0.0.1, and HTTP vs HTTPS)
- Fix log window pressing ctrl disables arrows and pgup/pgdn
- Fix crash when copying long headers from log
- Remove default port from URLs
- Fix activation of Apply button when page filters opened upon doubleclick

Due to the extent of changes to local filtering behaviour, please test this release very carefully and report back anything broken. I hope I haven't, but hope has not worked so well

(Jan. 05, 2019 04:00 AM)whenever Wrote:  If you turn on debug in the log window, then visit a https site say https://twitter.com, you will see the stylesheet for the dbug view is not applied. If you right click to view the source of that page, you will see the viewsrc.css is inserted via href="http://....." and that's why it's not loaded on a https site. That http:// thing is hardcoded in the program so it needs to be adjusted to automatically adapt to the protocol of the page. Besides viewsrc.css, this needs to be changed for all other local.ptron resources.

Fixed in 4.6.0.4.

(Jan. 07, 2019 05:54 AM)JJoe Wrote:  Starting with "4.6.0.0", "127.0.0.1:8080.pinfo" pages can not be filtered.
Could we have the old behavior back?

Fixed in 4.6.0.4.

(Jan. 07, 2019 05:54 AM)JJoe Wrote:  Starting with "4.6.0.0", "127.0.0.1:8080" requests are not displayed at "/.pinfo/urls".
Could we have the old behavior back?

Fixed in 4.6.0.4.

(Jan. 08, 2019 01:36 AM)whenever Wrote:  Another suggestion is to remove MD5, SHA1 and SHA224 from the Signature Algorithm drop down menu. They are either not secure any more or not approved for use with publicly trusted certificates. I can also foresee by removing them will also avoid new users complaining their browsers not working with the certificates and blaming it to Proxomitron.

I am leaving these in for backward compatibility. Incidentally, Proxomitron's SSL filtering now means you can use TLS 1.2 with browsers that don't even support TLS 1.0

(Feb. 05, 2019 02:42 AM)JJoe Wrote:  Opera (Chrome) alerts 'Mixed Content' and blocks access to http://local.ptron/ViewSrc.css when using 'HTML Debug Info' on HTTPS pages.

Fixed in 4.6.0.4.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Crashes with OpenSSL 1.0.2k, works with 1.0.1l: OpenSSL: FATAL OPENSSL_Uplink(6D857000,08): no OPENSSL_Applink

Not a bug. It does not support OpenSSL 1.0.2 yet, and probably never will because I am planning to get 1.1.x working in a future release.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Message log: pressing ctrl disables arrows and pgup/pgdn; next pressing ctrl enables them.

Fixed in 4.6.0.4.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Also Naoko-4.5 2003-6-1 crashed on copying long strings from log (over 1KB crap like Content-Security-Policy; don't have a sample).

Fixed in 4.6.0.4.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  4603R and Naoko-4.5 2003-6-1 don't allow downloading files >4GB - they break connection on border filesize & 0xFFFFFFFF (low 32 bits).

Known limitation. It is already on the list of improvements along with removing all the 64K limits from the filtering engine. Since you ask, I will raise its priority a little.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Support launching of multiple independed Proxomitrons (from different dirs: c:\Prox1, c:\Prox2; with their own different configs).

Your feature has been added to the list of requests. Will need to think about how to implement this.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Font setting for filter editor and testing dialogs.

Feature added to list of requests.

(Apr. 08, 2019 01:03 PM)DullFace Wrote:  Changing 'Host:' header name case and SNI manipulation for bypassing censorship: remove, replace, append space/dot/semicolon, uppercase

There are various reasons why I do not believe Proxomitron is the right place to implement such functionality, consider using a VPN or other dedicated "firewall breaker" instead.

[whenever]

Thanks so much for the update! Is there anyway I can buy you a beer or support the development?

Just found an issue with the local filtering. If you put local.ptron:443 in the bypass list then you will get below error while accessing local resource.

Code:

BlockList 3441: in Bypass-List, line 19

+++SSL 3441:+++
SSL Pass-Thru: CONNECT https://local.ptron:443/
SSL Pass-Thru Failed!
+++CLOSE 3441+++

It seems now https://local.ptron:xxx/ works with any ports. Maybe the HTTPS port number is not needed any more in the settings. Users tend to put that number in their browser proxy settings and removing it might eliminate the confusion.

BTW, What does "Remove default port from URLs" really mean?

[amy]

(Apr. 24, 2019 01:51 PM)whenever Wrote:  Thanks so much for the update! Is there anyway I can buy you a beer or support the development?

Making feature requests and bug reports is support enough

(Apr. 24, 2019 01:51 PM)whenever Wrote:  Just found an issue with the local filtering. If you put local.ptron:443 in the bypass list then you will get below error while accessing local resource.

Code:

BlockList 3441: in Bypass-List, line 19

+++SSL 3441:+++
SSL Pass-Thru: CONNECT https://local.ptron:443/
SSL Pass-Thru Failed!
+++CLOSE 3441+++

You asked it to bypass connections matching the host 'local.ptron:443', so it does exactly as you asked and you get the same result as trying to visit https://local.ptron in a browser without Proxomitron, i.e. it will attempt to resolve the hostname and connect to port 443. It's behaving like a bypass should, so I would not consider it to be a bug.

(Apr. 24, 2019 01:51 PM)whenever Wrote:  It seems now https://local.ptron:xxx/ works with any ports. Maybe the HTTPS port number is not needed any more in the settings. Users tend to put that number in their browser proxy settings and removing it might eliminate the confusion.

It is needed. Otherwise, what port would it listen on to serve HTTPS?

Also, some browsers can use HTTPS to connect to the proxy, which will encrypt the connection between the browser and Proxomitron itself: http://i.imgur.com/TGIEk8c.jpg --- you can use the HTTPS port for that as well as serving local resources. It is quite useful, because it means that e.g. if you use Proxomitron over the Internet, you can get encryption to your machine even when accessing regular HTTP websites, so it behaves like an "inverse half-SSL mode". Between the site's server and Proxomitron itself, the connection remains unencrypted.

(Apr. 24, 2019 01:51 PM)whenever Wrote:  BTW, What does "Remove default port from URLs" really mean?

If the protocol is http and the port is 80, or the protocol is https and the port is 443, then the port is treated as not explicitly specified.

[whenever]

(Apr. 25, 2019 12:14 PM)amy Wrote:  You asked it to bypass connections matching the host 'local.ptron:443', so it does exactly as you asked and you get the same result as trying to visit https://local.ptron in a browser without Proxomitron, i.e. it will attempt to resolve the hostname and connect to port 443. It's behaving like a bypass should, so I would not consider it to be a bug.

I wouldn't disagree but isn't local.ptron a special hostname to Proxomitron?

(Apr. 25, 2019 12:14 PM)amy Wrote:  It is needed. Otherwise, what port would it listen on to serve HTTPS?

8443 is set in config for https. I tried below ports and all of them worked.

https://local.ptron:8443/.pinfo/
https://local.ptron:453/.pinfo/
https://local.ptron:8999/.pinfo/

(Apr. 25, 2019 12:14 PM)amy Wrote:  you can use the HTTPS port for that as well as serving local resources

It's great! I just tested the https proxy and found I could only visit http web site but not https web site.

(Apr. 25, 2019 12:14 PM)amy Wrote:  Making feature requests and bug reports is support enough

You got it. Here are some suggestions.

- Make the config and lists to use utf-8 encoding

- For now Proxomitron can match on bytes like [%E9][%AB][%98][%E7]. Please make it capable of replacing with bytes too. Maybe via a command like $HEX([%E9][%AB][%98][%E7]).

- For the debug view, Proxomitron always return "Content-Type: text/html" while the server may return "Content-Type: text/html; charset=UTF-8". With the charset absent, the browser always takes the default value of ISO-8859-1, which will usually cause problems on non-western pages. The suggest is to let Proxomitron to return what the server returns on Content-Type header.

[mizzmona]

(Apr. 26, 2019 02:47 AM)whenever Wrote:  

(Apr. 25, 2019 12:14 PM)amy Wrote:  You asked it to bypass connections matching the host 'local.ptron:443', so it does exactly as you asked and you get the same result as trying to visit https://local.ptron in a browser without Proxomitron, i.e. it will attempt to resolve the hostname and connect to port 443. It's behaving like a bypass should, so I would not consider it to be a bug.

I wouldn't disagree but isn't local.ptron a special hostname to Proxomitron?

Well, there seems to be some confusion here. Certainly, local.ptron is a special hostname, but the point is that the Bypass list isn't a blocklist to kill connections, it's a list to deactivate filtering. These are two different things. Local.ptron should still be accessible if included on the Bypass list, just as it should be accessible when the Proxomitron itself is placed in bypass mode.

I'm dying to find some solid time to play with this new version myself, though. Whenever, you lucky dog...

Thank you, amy! This is just sooo awesome.

[JJoe]

(Apr. 26, 2019 08:13 AM)mizzmona Wrote:  Well, there seems to be some confusion here.

I think Reborn has hidden 'filters' for "local.ptron" connections that are applied after "Bypass any URLs that match this expression" is checked.
Something like "local.ptron:&$RDIR(https://local.ptron:8443)".

So, if you bypass a "local.ptron" connection to a nonexistent port, the hidden routine can't redirect the connection to the correct port and the attempt fails.
Which, if correct, is "behaving like a bypass should" and confusing.

There may be a 'bug', however...

To bypass "local.ptron:" and maintain a 'catch-all' for nonexistent ports my bypass list needs

Code:

line 21: local.ptron:&$RDIR(https://local.ptron:8443)
line 22: /

Line 21 applies to the 'CONNECT'.
Line 22 applies to the 'GET'.

Should the first line be enough???

log window Wrote:RedirectTo: https://local.ptron:8443/
BlockList 1352: in Bypass-List, line 21

+++SSL 1352:+++
SSL Pass-Thru: CONNECT https://local.ptron:8443/
BlockList 1353: in Bypass-List, line 22

+++SSL:GET 1353+++
SSL cipher TLSv1.2 AES128-GCM-SHA256 (128 bits)
GET /.pinfo/ HTTP/1.1
Host: local.ptron:453
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
+++CLOSE 1353+++
+++CLOSE 1352+++

Edit:

It looks like matching the CONNECT header removes the need or ability to match the HOST in the GET.

If I add to bypass

Code:

Line 24: local.ptron  
Line 25: local.ptron:8443/.pinfo/
Line 26: /.pinfo/

then

log window Wrote:BlockList 1704: in Bypass-List, line 24

+++SSL 1704:+++
SSL Pass-Thru: CONNECT https://local.ptron:8443/
BlockList 1705: in Bypass-List, line 26

+++SSL:GET 1705+++
SSL cipher TLSv1.2 AES128-GCM-SHA256 (128 bits)
GET /.pinfo/ HTTP/1.1
Host: local.ptron:8443
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
+++CLOSE 1705+++
+++CLOSE 1704+++

If only

Code:

Line 25: local.ptron:8443/.pinfo/

then

log window Wrote:+++GET 1738+++
CONNECT / HTTP/1.1
Host: local.ptron:8443
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
BlockList 1738: in Bypass-List, line 25

+++SSL:GET 1738+++
SSL cipher TLSv1.2 AES128-GCM-SHA256 (128 bits)
GET /.pinfo/ HTTP/1.1
Host: local.ptron:8443
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
+++CLOSE 1738+++

[whenever]

A new bug is caught.

If you have https filtering enabled, clicking Abort while Active connections is NOT 0 will make Proxomitron refuse accepting new connections.


  Abort.png (Size: 5.06 KB / Downloads: 519)

While the Aborting is finished, the log window shows below message. Seems to be a ports binding issue.

Code:

Listening on port 8443
Listening on port 8080

The problem doesn't appear to happen if you have https filtering disabled (Untick Use SSLeay/OpenSSL in HTTP tab of the settings).

Some feature thoughts for discussion.

1. The debug view shows incoming headers now. What about showing outgoing headers (with any header filters applied) too?

2. Improve the proxy testing function.

Quote:Testing a proxy

The Proxomitron can perform a "loopback" test on an external proxy. During the test the Proxomitron makes a request for a web page - through the remote proxy - back to itself. It then monitors both ends of the conversation. Use it to tell if a particular proxy server is accessible and available for use.

The original test connects back to the host where Proxomitron is running. It works at the age where Proxomitron was just born and everybody had a public IP address but now most users are behind a router/NAT and have a private IP address so the "loopback" test barely works.

The suggest is to make the destination a user configurable external URL.

3. Port Proxomitron to Linux world so that we can run it on our routers. A command line only version is enough.

[amy]

(Apr. 26, 2019 02:47 AM)whenever Wrote:  - Make the config and lists to use utf-8 encoding

Is there a specific reason for this feature request? Currently, Proxomitron is "encoding-agnostic" --- or perhaps more precisely, "encoding-ignorant". It matches bytes with bytes. I have seen lots of other systems break when given unusual-yet-reasonable inputs because they weren't, and Proxomitron gets subjected to lots of such input, so I am in general against adding such a fragile layer of complexity.

(Apr. 26, 2019 02:47 AM)whenever Wrote:  - For now Proxomitron can match on bytes like [%E9][%AB][%98][%E7]. Please make it capable of replacing with bytes too. Maybe via a command like $HEX([%E9][%AB][%98][%E7]).

I believe if you write directly "éｫ˜ç" in the replacement dialog, you will get the behaviour you desire. Some more escapes would be nice, however, so this has been added to the list of feature requests.

(Apr. 26, 2019 02:47 AM)whenever Wrote:  - For the debug view, Proxomitron always return "Content-Type: text/html" while the server may return "Content-Type: text/html; charset=UTF-8". With the charset absent, the browser always takes the default value of ISO-8859-1, which will usually cause problems on non-western pages. The suggest is to let Proxomitron to return what the server returns on Content-Type header.

Added to feature request list.

(Apr. 30, 2019 09:16 AM)whenever Wrote:  If you have https filtering enabled, clicking Abort while Active connections is NOT 0 will make Proxomitron refuse accepting new connections.

Abortion is difficult. I haven't been able to reproduce(pun not intended) this, and I've been using https filtering for years, but I have a feeling I know what's causing it --- this is a design defect which has always been there in Scott's releases, that I haven't had the time to fix, because a full fix is not easy, but I've increased the priority of it now that you're seeing problems. (Technical details: Instead of closing all active connection socket handles, it just keeps track of the minimum and maximum socket handles, and closes them all by looping through them sequentially. It's a quick-and-dirty way to add this function, but may end up closing some other unrelated handles too. I was actually a bit shocked when I first discovered this.)

(Apr. 30, 2019 09:16 AM)whenever Wrote:  While the Aborting is finished, the log window shows below message. Seems to be a ports binding issue.

Code:

Listening on port 8443
Listening on port 8080

The problem doesn't appear to happen if you have https filtering disabled (Untick Use SSLeay/OpenSSL in HTTP tab of the settings).

That is the normal message and has nothing to do with the defect mentioned above. Using OpenSSL filtering may change the memory allocation and general environment enough to make it appear.

(Apr. 30, 2019 09:16 AM)whenever Wrote:  1. The debug view shows incoming headers now. What about showing outgoing headers (with any header filters applied) too?

Added to feature request list.

(Apr. 30, 2019 09:16 AM)whenever Wrote:  2. Improve the proxy testing function.
...
The suggest is to make the destination a user configurable external URL.

Added to feature request list.

(Apr. 30, 2019 09:16 AM)whenever Wrote:  3. Port Proxomitron to Linux world so that we can run it on our routers. A command line only version is enough.

That's not a feature request, that's more like a "new version" request! Not to say I won't do it, however, because one of other items already on the list is "Android support". That won't be any time soon, as you may expect...

[amy]

Now, regarding the long discussion on local.ptron and local resources etc.; it's subtle enough that I've attached a diagram of the processing flow that Proxomitron Reborn goes through when it handles a request, because it's difficult to explain with words alone.

Consider what happens when you try to visit https://local.ptron/ when it's bypassed:
1. Browser connects to Proxomitron
2. Browser sends CONNECT local.ptron:443
3. Proxomitron decides this host is bypassed.
4. It goes into the "Resolve hostnames, ... Do Read/Write Tunnel" flow.
This resolves local.ptron to 127.0.0.1 and then initiates a connection to port 443 on the local machine. If you don't have something listening on that port, or it's not an HTTPS server, then it fails to connect.

When it's not bypassed:
1. Browser connects to Proxomitron
2. Browser sends CONNECT local.ptron:443
3. Proxomitron decides this host is not bypassed.
4. It processes outgoing header filters if enabled.
5. It writes "connection established" to the client, does a TLS handshake with it (using its own certificate), and reads the request line (which will simply be GET / HTTP/1.1)
6. It turns this into https://local.ptron/ internally and then continues with the non-CONNECT flow, i.e. eventually gets to serving from the internal HTTP server. Note that processing of "/.pinfo/" takes a separate path, which explains JJoe's observation: "While "local.ptron/.pinfo" pages can not be filtered, "127.0.0.1:8080/.pinfo" pages could."

127.0.0.1:8080/.pinfo/ will be filtered, because that involves Proxomitron connecting back to itself and filtering what comes through; one connection serves the info page, which gets filtered through the second connection. For now, I'll leave it to you to figure out what happens when https:// is involved...

[whenever]

(May. 02, 2019 12:01 PM)amy Wrote:  Is there a specific reason for this feature request? Currently, Proxomitron is "encoding-agnostic" --- or perhaps more precisely, "encoding-ignorant".

Proxomitron is a non-Unicode program and windows has a setting for these kind of programs:



For Chinese users it means the default encoding is GB2312. When you input Chinese characters in the Match or Replace dialog of the Proxomitron program, the characters are GB2312 encoded first before being save to the config file.

The same Chinese character takes 2 bytes under GB2312 encoding, or 3 bytes under UTF-8 encoding.



Nowaday, most webpages use utf-8 as their encoding, which means Proxomitron can't do the match directly. Fortunately I can use the byte level form "[%E4][%B8][%80]" to match but obviously it's not friendly.

I'm using Chinese as the example but it's a problem for ALL users whose language needs at least 2 bytes to encode.

I just want to explain the reason why it might be an important improvement. I fully understand it might be tricky to turn Proxomitron into a Unicode program.

[whenever]

(May. 02, 2019 12:01 PM)amy Wrote:  

(Apr. 30, 2019 09:16 AM)whenever Wrote:  While the Aborting is finished, the log window shows below message. Seems to be a ports binding issue.

Code:

Listening on port 8443
Listening on port 8080

The problem doesn't appear to happen if you have https filtering disabled (Untick Use SSLeay/OpenSSL in HTTP tab of the settings).

That is the normal message and has nothing to do with the defect mentioned above. Using OpenSSL filtering may change the memory allocation and general environment enough to make it appear.

You once mentioned:

Quote:You will still see two messages in the log when you abort (which restarts the listeners) if you have both ports enabled, however.

I think we may have 2 ways to abort:

1. Don't restart the listeners, and close all active connection socket handles, or
2. Restart the listeners

For way 2, I'm not sure if it is needed to unbind the ports first so that the restarted listeners can rebind them. I'm not familiar with this so this is just an irresponsible guess.

[whenever]

(May. 02, 2019 12:15 PM)amy Wrote:  Now, regarding the long discussion on local.ptron and local resources etc...

So this is what I get now:

If you don't bypass local.ptron

you can visit local resources via https://local.ptron:XXX/path, where XXX could be any number no matter what is set for https proxy, because local.ptron is treated specially at step 6.

If you do bypass local.ptron

you can only visit local resources via https://local.ptron:XXX/path, where XXX has to be the number you set for https proxy, because local.ptron is not treated specially under this situation (though wondering if it could be improved at step 4 to redirect the connection to the correct port?).

For config users who have different https port settings from config authors, it's suggested to follow JJoe's suggestion.

Quote:To bypass "local.ptron:" and maintain a 'catch-all' for nonexistent ports my bypass list needs

Code:

local.ptron:&$RDIR(https://local.ptron:XXX)

Where XXX is the number you set for https proxy.