• HTTP everywhere

    From Lu Wei@21:1/5 to All on Wed Mar 22 16:24:29 2023
    For some known or unknown reasons HTTPS may not work for a site while
    HTTP works. I'd like to have a simple way to switch all HTTPS links to
    HTTP. Is there any solution?
    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Lu Wei on Wed Mar 22 04:45:10 2023
    Lu Wei <[email protected]> wrote:

    For some known or unknown reasons HTTPS may not work for a site while
    HTTP works. I'd like to have a simple way to switch all HTTPS links to
    HTTP. Is there any solution?

    HTTP may not work at some sites, too. Depends on how the site is setup.
    Some will accept HTTPS connects but disallow HTTP connects. Some rely
    on an initial HTTP connect, and then redirect you to their HTTPS page.

    HTTPS Everywhere has a whitelist.

    You may not need it, though. Many web browsers have an "HTTPS always"
    setting that first tries HTTPS to a site. If that fails, you get
    prompted if you want to allow HTTP. You can add an exception for a site
    to eliminate the prompt. For example, Firefox has its HTTPS-Only Mode,
    but you can add exceptions. You never mentioned which web browser(s)
    you use.

    I used HTTPS Everywhere many years ago. I quit using it because of the nuisance of continually adding exceptions, but exceptions could be
    defined (whitelisting). As I recall, HTTPS Everywhere came bundled with
    a load of exceptions. So, add another.

    https://www.eff.org/https-everywhere/faq#what-if-https-everywhere-breaks-some-site-that-i-use

    The HTTPS Everywhere add-ons has become obsolete. Alas, you are on
    Windows XP, and many web browsers discontinued supporting that OS a long
    time ago, so are likely using an old version of the web browser, and it
    may not have HTTPS-only mode. For Firefox, HTTPS-Only Mode appeared in
    version 83. Since you are on Windows XP, Firefox 52 ESR was the last
    version that supported Windows XP. So, I guess you're stuck using HTTPS Everywhere, and adding exceptions.

    A simple way to switch all HTTP links to use HTTP (instead of first
    trying HTTPS) is to remove the HTTPS Everywhere add-on. When connecting
    via HTTP, the add-on won't be present to instead try HTTPS.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to VanguardLH on Thu Mar 23 09:10:23 2023
    On 2023-3-22 17:45, VanguardLH wrote:
    ...
    Firefox 52ESR is obsolete; The browser I am using is Serpent 52, a
    Basilisk branch (which is originally forked from Firefox 52ESR) for
    Windows XP, and occasionally 360Chrome 13, a Chrome 86 fork for Windows XP.

    What I need to do, is the contrary of HTTPS Everywhere: it should try
    HTTP first, even if the link is HTTPS, and disregard the page
    redirection to HTTPS, or rewrite all HTTPS connection to HTTP.

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Lu Wei on Thu Mar 23 03:56:48 2023
    Lu Wei <[email protected]> wrote:

    On 2023-3-22 17:45, VanguardLH wrote:
    ...
    Firefox 52ESR is obsolete; The browser I am using is Serpent 52, a
    Basilisk branch (which is originally forked from Firefox 52ESR) for
    Windows XP, and occasionally 360Chrome 13, a Chrome 86 fork for Windows XP.

    What I need to do, is the contrary of HTTPS Everywhere: it should try
    HTTP first, even if the link is HTTPS, and disregard the page
    redirection to HTTPS, or rewrite all HTTPS connection to HTTP.

    HTTP first and switch to HTTPS is what the sites do. You don't need an
    add-on to do that. Specify HTTP when you connect. Then it is up to the
    site to redirect you to their HTTPS page *if* they have a site
    certificate (which is both to identify themself as well as provide for
    the encryption of HTTPS).

    HTTP ---> site -----> HTTP
    '--> HTTPS

    If they don't operate an HTTPS site, their HTTP connect goes to their
    HTTP web page. If they do operate an HTTPS site, they will redirect
    HTTP connects to their HTTPS documents (if they have a site cert, and
    configure their web server to do the redirect).

    http://intel.com redirects to https://www.intel.com/content/www/us/en/homepage.html

    http://gamespot.com redirects to
    https://www.gamestop.com/

    http://www.troubleshooters.com/codecorn/littperl/perlreg.htm
    (no redirection)
    (they don't have a site cert, and don't support HTTPS connects)

    If you are intent on using HTTPS Everywhere, it should let you add
    exceptions. In fact, I thought updates to the add-on were to update its baseline exceptions list based on reports from its users on problematic
    web sites. Since they update their exceptions list, you are not allowed
    to add to that whitelist, or define your own to use in conjuction with
    theirs?

    You want the opposite behavior from the add-on. To get that, uninstall
    the add-on, and let the sites redirect you from HTTP to HTTPS if they
    have a site cert and web server setup to do HTTPS connects. If they
    don't have HTTPS connects, the add-on isn't going to help you, anyway,
    if they don't support HTTPS connects.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to VanguardLH on Thu Mar 23 17:30:05 2023
    On 2023-3-23 16:56, VanguardLH wrote:
    ...
    I want to disable the redirection to HTTPS. For example if http://intel.com redirects to https://www.intel.com/content/www/us/en/homepage.html, then I'd like to connect to http://www.intel.com/content/www/us/en/homepage.html instead. And all links and
    forms on the following page should go through HTTP. I don't even want it to try HTTPS if HTTP failed, because this HTTP-only mode is for those HTTPS failing sites, whether it is site's fault or not.

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Lu Wei on Thu Mar 23 04:50:00 2023
    Lu Wei <[email protected]> wrote:

    I want to disable the redirection to HTTPS. For example if
    http://intel.com redirects to https://www.intel.com/content/www/us/en/homepage.html,
    then I'd like to connect to http://www.intel.com/content/www/us/en/homepage.html
    instead. And all links and forms on the following page should go
    through HTTP. I don't even want it to try HTTPS if HTTP failed,
    because this HTTP-only mode is for those HTTPS failing sites, whether
    it is site's fault or not.

    You don't get that choice. Everytime you attempt an HTTP connect to the
    Intel web server, their web server will redirect you to their HTTPS
    page. The redirection is done at the server, and you have no control
    whether the redirection happens or not.

    The HTTP Everywhere add-on is modifying the protocol in the URL from
    http:// to https:// *before* you even connect to the web server. That
    is a local modification.

    Trying to connect to http:// and the site redirecting to https:// is a server-side redirection. You have no control over that. They do NOT
    have an HTTP page, only HTTPS. If the HTTPS connect fails to the web
    site, they don't have an HTTP page for you to fallback to.

    Do you have an example of a web site where HTTPS connects fail, but the
    site really does have an HTTP page to which you can connect (that the
    server doesn't then redirect to an HTTPS page)?

    So, what's the real reason you want to do this? Are you trying to use a
    web crawler to steal the content of a web site, but your web crawler
    only supports HTTP connects?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to VanguardLH on Fri Mar 24 10:30:19 2023
    On 2023-3-23 17:50, VanguardLH wrote:
    Lu Wei <[email protected]> wrote:

    I want to disable the redirection to HTTPS. For example if
    http://intel.com redirects to https://www.intel.com/content/www/us/en/homepage.html,
    then I'd like to connect to http://www.intel.com/content/www/us/en/homepage.html
    instead. And all links and forms on the following page should go
    through HTTP. I don't even want it to try HTTPS if HTTP failed,
    because this HTTP-only mode is for those HTTPS failing sites, whether
    it is site's fault or not.

    You don't get that choice. Everytime you attempt an HTTP connect to the Intel web server, their web server will redirect you to their HTTPS
    page. The redirection is done at the server, and you have no control
    whether the redirection happens or not.

    The HTTP Everywhere add-on is modifying the protocol in the URL from
    http:// to https:// *before* you even connect to the web server. That
    is a local modification.

    Trying to connect to http:// and the site redirecting to https:// is a server-side redirection. You have no control over that. They do NOT
    have an HTTP page, only HTTPS. If the HTTPS connect fails to the web
    site, they don't have an HTTP page for you to fallback to.

    I think the page should be the same files in the server's disk; but you are right, if the server just keeps redirecting HTTP request to HTTPS instead of serving the page, I have no way out. The HTTP-only mode when it is useful, is when HTTP request does
    work, but (the default) HTTPS fail.

    Do you have an example of a web site where HTTPS connects fail, but the
    site really does have an HTTP page to which you can connect (that the
    server doesn't then redirect to an HTTPS page)?

    An example: http://fankui.dongtaiwang.net/index.php?board=2.0
    All links on the page are HTTPS which would get time out, but changing to HTTP manually would work. I have a bookmarklet:
    javascript:(function(){location.href=location.href.replace(/^https\:/,"http:");})()
    But it only works *after* the URL time out.

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Lu Wei on Thu Mar 23 22:10:20 2023
    Lu Wei <[email protected]> wrote:

    VanguardLH wrote:

    Lu Wei <[email protected]> wrote:

    I want to disable the redirection to HTTPS. For example if
    http://intel.com redirects to https://www.intel.com/content/www/us/en/homepage.html,
    then I'd like to connect to http://www.intel.com/content/www/us/en/homepage.html
    instead. And all links and forms on the following page should go
    through HTTP. I don't even want it to try HTTPS if HTTP failed,
    because this HTTP-only mode is for those HTTPS failing sites,
    whether it is site's fault or not.

    You don't get that choice. Everytime you attempt an HTTP connect to
    the Intel web server, their web server will redirect you to their
    HTTPS page. The redirection is done at the server, and you have no
    control whether the redirection happens or not.

    The HTTP Everywhere add-on is modifying the protocol in the URL from
    http:// to https:// *before* you even connect to the web server.
    That is a local modification.

    Trying to connect to http:// and the site redirecting to https:// is
    a server-side redirection. You have no control over that. They do
    NOT have an HTTP page, only HTTPS. If the HTTPS connect fails to
    the web site, they don't have an HTTP page for you to fallback to.

    I think the page should be the same files in the server's disk; but
    you are right, if the server just keeps redirecting HTTP request to
    HTTPS instead of serving the page, I have no way out. The HTTP-only
    mode when it is useful, is when HTTP request does work, but (the
    default) HTTPS fail.

    Do you have an example of a web site where HTTPS connects fail, but
    the site really does have an HTTP page to which you can connect
    (that the server doesn't then redirect to an HTTPS page)?

    An example: http://fankui.dongtaiwang.net/index.php?board=2.0 All
    links on the page are HTTPS which would get time out, but changing to
    HTTP manually would work. I have a bookmarklet: javascript:(function(){location.href=location.href.replace(/^https\:/,"http:");})()
    But it only works *after* the URL time out.

    When I visit the HTTP page, yep, it's HTTP and does not get redirected
    to an HTTPS page by their web server. When I click on a hyperlink, I'm
    taken to HTTPS pages - but they show up, and do not time out.

    Have you tried visiting that HTTP site *without* HTTPS Everywhere
    interferring? Disable the HTTPS Everywhere, and try the hyperlinks on
    that web site again. You could add an exception to HTTPS Everywhere to
    see if that works with the add-on active.

    I gave up on the HTTPS Everywhere add-on, because I kept hitting sites
    where its algorithm caused problems. I couldn't connect to a lot of
    sites until I added them as exceptions. I reported the problematic web
    pages to the add-on author who would eventually include the sites in
    his bundled whitelist. But I'd have to wait until then to remove the
    exception (to use his exception). He wasn't fixing his algorithm. He
    was just adding an exception to nullify his add-on when visiting the problematic sites.

    I gave up with the constant nuisance of using HTTPS Everywhere. I had
    to keep adding exceptions. It was easier to discard the add-on, and
    let the web server decide when it would present HTTP or HTTPS.

    Even Firefox has its HTTPS-only mode that connects only with https://
    web sites. I have to keep overriding it trying to force HTTPS
    connects. I could add exceptions, but: (1) I'm back to the same
    nuisance of having to keep adding exceptions as I did with HTTPS
    Everywhere, and; (2) I configure Firefox to purge *all* its locally
    cached data on its exit, and that include Site Preferences where the
    exceptions are stored. HTTPS-only Mode in Firefox became just as much
    a nuisance as was HTTPS Everywhere. I got rid of both: dumped the
    add-on, and disabled the HTTPS-only mode.

    There are far too many HTTP sites still around. A site that doesn't
    have you login, or otherwise present private data, doesn't need
    encryption. All its content is public. The only other purpose for a
    site certificate is to try to ensure the site you reach is the one you
    intended to visit. Site certs are for site identification and for
    encryption. If a site isn't interested in ensuring its visitors that
    they reached the correct site, and if nothing requires encryption, then
    there is not point to using HTTPS with all its headaches to setup and
    maintain.

    Despite what users like to regurgitate from article they read that were
    simply written by other users regurgitating the same misinformation,
    HTTP is *not* dead.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From AugustA@21:1/5 to All on Fri Mar 24 08:01:00 2023
    Hello V!

    There are far too many HTTP sites still around. A site that
    doesn't have you login, or otherwise present private data,
    doesn't need encryption. All its content is public. The only
    other purpose for a site certificate is to try to ensure the
    site you reach is the one you intended to visit. Site certs
    are for site identification and for encryption.

    A site admin can still lock down a site without a certif, and
    make sure that the connection is https. Even without a certif,
    https is useful in the sense that the admin's login and pw is
    protected from being broadcast.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to AugustA on Sat Mar 25 00:36:05 2023
    AugustA <[email protected]> wrote:

    A site admin can still lock down a site without a certif, and
    make sure that the connection is https. Even without a certif,
    https is useful in the sense that the admin's login and pw is
    protected from being broadcast.

    Without a cert, how is encryption of web traffic to prevent snooping
    during transmission from client to server? Most users no longer want to
    send their login credentials in the clear (plain text).

    A <form> can have an input element in an HTTP page, but to be secured
    the onsubmit attribute points at an HTTPS page to encrypt the login
    credentials transmitted from HTTP page (in the client) to the HTTPS page
    (at the server delivered to the client), and a cert will be needed for
    the HTTPS page.

    Please explain how a site can provide HTTPS pages without a cert. Even
    if it be a self-signed cert, the cert is needed to do the encryption.
    HTTPS is HTTP-within-SSL, a tunneling protocol. With HTTPS the client
    is also the SSL client. HTTPS piggybacks HTTP atop of TLS.

    HTTP Over TLS
    https://www.rfc-editor.org/rfc/rfc2818

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to VanguardLH on Sat Mar 25 16:44:13 2023
    On 2023-3-24 11:10, VanguardLH wrote:
    Lu Wei <[email protected]> wrote:
    An example: http://fankui.dongtaiwang.net/index.php?board=2.0 All
    links on the page are HTTPS which would get time out, but changing to
    HTTP manually would work. I have a bookmarklet:
    javascript:(function(){location.href=location.href.replace(/^https\:/,"http:");})()
    But it only works *after* the URL time out.

    When I visit the HTTP page, yep, it's HTTP and does not get redirected
    to an HTTPS page by their web server. When I click on a hyperlink, I'm
    taken to HTTPS pages - but they show up, and do not time out.

    They may show up for you, but not for me: I have to visit that site
    through proxy because the direct connection is blocked by the Great
    Firewall, and maybe HTTPS negotiation through the proxy is interrupted
    also. HTTP-only mode is the solution for this case.

    Have you tried visiting that HTTP site *without* HTTPS Everywhere interferring? Disable the HTTPS Everywhere, and try the hyperlinks on
    that web site again. You could add an exception to HTTPS Everywhere to
    see if that works with the add-on active.

    I have no experience with HTTPS Everywhere; never need that. The concern
    of internet users of china is accessibility rather than security or privacy.

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Lu Wei on Sat Mar 25 12:14:27 2023
    Lu Wei <[email protected]> wrote:

    VanguardLH wrote:

    Lu Wei <[email protected]> wrote:

    An example: http://fankui.dongtaiwang.net/index.php?board=2.0 All
    links on the page are HTTPS which would get time out, but changing to
    HTTP manually would work. I have a bookmarklet:
    javascript:(function(){location.href=location.href.replace(/^https\:/,"http:");})()
    But it only works *after* the URL time out.

    When I visit the HTTP page, yep, it's HTTP and does not get redirected
    to an HTTPS page by their web server. When I click on a hyperlink, I'm
    taken to HTTPS pages - but they show up, and do not time out.

    They may show up for you, but not for me: I have to visit that site
    through proxy because the direct connection is blocked by the Great
    Firewall, and maybe HTTPS negotiation through the proxy is interrupted
    also. HTTP-only mode is the solution for this case.

    Sounds like a defect in whatever VPN that you use in not supporting
    HTTPS. When the VPN exit node connects to the site, it becomes the
    client to the site and uses HTTPS, so traffic from exit node to site is encrypted. Traffic across the VPN should be encrypted. When your
    client connects to the VPN's entry node, it uses HTTPS, so traffic from
    entry node to your client is encrypted. Looks like a deficiency in
    whatever VPN you are using that HTTPS is not support at the exit or
    entry nodes, or both.

    China has banned VPNs not approved by them. They want the backdoor
    access which renders VPNs insecure. While companies and corporations
    are banned from operating entry/exit nodes within China, looks like the
    law does not apply to citizens operating their own VPNs.

    VPNs are not the secure transmission venue as touted. You have to trust
    the VPN service, or the operators of the entry and exit nodes, to not
    intercept your traffic to interrogate it. Since HTTPS is between exit
    node to site, and between you and entry node, that traffic is decrypted
    at the entry and exit nodes, so the VPN (and Tor nodes) could monitor
    your traffic if they want to. Rarely do you know the operators of the
    VPN or Tor nodes, so you're trusting your web content to unknowns. You
    can hope the big VPN providers are trustworthy. You haven't a clue what
    a private VPN operator is doing with your web traffic. VPNs and Tor are
    about trusting unknowns with your web traffic, but they're based on a
    trust model. They are to secure against outside interception and
    iterrogation of traffic, not for security within their network. Maybe
    they're safe, maybe not. You have to hope they're not watching. They
    can be used for other purposes, like working around geofencing, or, in
    your case, getting past a firewall to grant access the firewall would
    otherwise thwart providing the firewall doesn't block access between VPN
    or Tor nodes.

    For the VPN you are using, do they operate a web site (which could
    expose them to the Chinese gov't), or have a contact e-mail address, to
    get information on limitations of their VPN, or to report problems in
    using it? Just because they operate a VPN does not mean they support
    HTTPS at their entry or exit node, or they're supporting TLS 2.0, or
    later, rather than SSL or even TLS 1.0 (which is SSL 3.0, but with some handshaking differences that make SSL 3.0 and TLS 1.0 incompatible)
    which would be using unsupported ciphers by the client or site. To be compatible today, and for the past many years, the VPN should support
    HTTP via TLS. Alas, there are VPNs that are not very robust, and have
    some crippling limitations.

    https://www.vpnmentor.com/blog/nordvpn-works-china-first/

    That mentions how to get NordVPN to work with their obfuscated servers.
    The article says ExpressVPN is easier to set up. Those are commercial
    VPN operators, so banned in China. You'll have to check if your choice
    of VPN (aka proxy) operator has limitations on HTTPS (on either side of
    their proxy network).

    Have you tried visiting that HTTP site *without* HTTPS Everywhere
    interferring? Disable the HTTPS Everywhere, and try the hyperlinks on
    that web site again. You could add an exception to HTTPS Everywhere to
    see if that works with the add-on active.

    I have no experience with HTTPS Everywhere; never need that.

    Sorry, I thought you saying "HTTP everywhere" meant you were asking
    about the HTTPS Everywhere add-on from EFF. After 2 days of replies,
    now it's about you trying to find an add-on that does just the opposite
    by trying to force HTTPS connects to use HTTP. As mentioned, the site determines whether it uses HTTP or HTTPS. Even if you managed to force
    your web client to always use HTTP for the initial connection, most
    sites properly administered that support HTTPS will redirect HTTP
    connects to their HTTPS pages. You cannot force them to undo their
    automatic redirect.

    Seems the problem is with whomever's VPN/proxy you are using.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From AugustA@21:1/5 to All on Sun Mar 26 16:44:00 2023
    Hello V!

    ** On Saturday 25.03.23 - 01:36, V wrote to :

    Without a cert, how is encryption of web traffic to prevent
    snooping during transmission from client to server? Most
    users no longer want to send their login credentials in the
    clear (plain text).

    Perhaps my host offers built-in auto certifs or something.
    Dunno. But it was a simple matter to force https mode to
    visitors on my sites.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to VanguardLH on Mon Mar 27 10:50:17 2023
    On 2023-3-26 1:14, VanguardLH wrote:
    ... Sorry, I thought you saying "HTTP everywhere" meant you were
    asking about the HTTPS Everywhere add-on from EFF. After 2 days of
    replies, now it's about you trying to find an add-on that does just
    the opposite by trying to force HTTPS connects to use HTTP. As
    mentioned, the site determines whether it uses HTTP or HTTPS. Even
    if you managed to force your web client to always use HTTP for the
    initial connection, most sites properly administered that support
    HTTPS will redirect HTTP connects to their HTTPS pages. You cannot
    force them to undo their automatic redirect.

    Seems the problem is with whomever's VPN/proxy you are using.

    Thank you for the patience. I have pinned the bug: the problem is the auto-proxy-switching add-on does not honor the pattern rule "internetfreedom.org" for "https://forums.internetfreedom.org" (but it honors "http://forums.internetfreedom.org"!), so the
    browser tries connecting to it directly which would surely fail. I add a rule "||internetfreedom.org" and now it works. So it is the add-on's bug. It should comply with Adblock's syntax.

    But downgrading all HTTPS to HTTP is still a valid need, for sometimes HTTPS connection is interrupted by the GFW, even through proxy|VPN. In that case only HTTP page is accessible.

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to AugustA on Mon Mar 27 06:03:23 2023
    AugustA <[email protected]> wrote:

    V wrote:

    Without a cert, how is encryption of web traffic to prevent
    snooping during transmission from client to server? Most
    users no longer want to send their login credentials in the
    clear (plain text).

    Perhaps my host offers built-in auto certifs or something.
    Dunno. But it was a simple matter to force https mode to
    visitors on my sites.

    A lot of webhosters offer certs with their hosting service. Makes it
    easier than the site operator having to get a cert (some are free, like LetsEncrypt, some are paid) and getting it set up in their web server
    along with setting up redirect on HTTP connects to HTTPS connects.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lu Wei@21:1/5 to Lu Wei on Thu Mar 30 08:54:13 2023
    On 2023-3-27 10:50, Lu Wei wrote:

    But downgrading all HTTPS to HTTP is still a valid need, for sometimes HTTPS connection is interrupted by the GFW, even through proxy|VPN. In that case only HTTP page is accessible.

    I got a neat solution from: https://msfn.org/board/topic/184051-my-browser-builds-part-4/page/73/#comment-1242205
    A bookmarklet that rewrite all HTTPS link on the page to HTTP: javascript:document.body.innerHTML.split('https://').join('http://')

    --
    Regards,
    Lu Wei
    IM: xmpp:[email protected]
    PGP: 0xA12FEF7592CCE1EA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)