@Publison said:
Three ticks with a CR
control V to paste
CR then tree more ticks
(see above)
Hello!
I did. I must be missing something. Doesn't the Markdown concept have tags for creating code boxes?
I looked at the referenced entity where the forum says, "You can use Markdown in your post." But all I saw were the methods that the text boxes uses for creating what I am typing. Even looking at an old post of mine didn't help, it was simply one that was translated by the gang behind you @Publison , to glom all of our older forum postings.
Hello!
I see your point. @VonSzarvas instead of using the Wikipedia definition of Markdown which does not go into enough detail why don't we use the Github explanation? I found exactly what @rosco_pc and even @Publison was getting at in there. Besides what you're thinking of as back ticks have a more complicated definition some place else.
New problem. I am finishing a commentary response to what @"Duane Degn" presented. And towards the end, the back end kept causing Chrome to put up its "Page Unresponsive" pop up. And naturally I was wondering what the <BLEEP!> the site was doing that kept causing that. I found it annoying that it kept interrupting me to do something else, and take very long to do it. I suspect that it was that strange lag that was earlier reported.
It's a buggy script, from the webpage, running in the browser. The browser is complaining that the script is taking too long to execute. The real problem is that javascript even exists.
@evanh said:
It's a buggy script, from the webpage, running in the browser. The browser is complaining that the script is taking too long to execute. The real problem is that javascript even exists.
Now there's an idea. In fact I agree. That scripting language should have been tossed aside. Depending on what the backend platform is for this site, I shall accept several, amongst them are PHP, and then the ASP stuff, and finally good old fashioned plain HTML.
No software updates, but we did upgrade the load balancer that sits in front of the web server yesterday afternoon. What you are describing sounds like that PC is using the old load balancer IP address.
@"Jim Ewald" said:
No software updates, but we did upgrade the load balancer that sits in front of the web server yesterday afternoon. What you are describing sounds like that PC is using the old load balancer IP address.
My browser seems to time out very quickly. Is there anything I could try or you could change? Accessing the forum was fine for ages until yesterday.
That's more of a broken connection type message. One that the browser is still trying to restore long after its gone. Usually closing the tab and starting again works but maybe just reboot the whole computer to be sure. EDIT: And reboot the router or modem too.
How are you posting here at the moment? Is it via the same LAN/ISP connection?
@evanh said:
That's more of a broken connection type message. One that the browser is still trying to restore long after its gone. Usually closing the tab and starting again works but maybe just reboot the whole computer to be sure. EDIT: And reboot the router or modem too.
How are you posting here at the moment? Is it via the same LAN/ISP connection?
Hello!
It's quite possible that our friend back there did do all of that, which is why that post was successful. As to the rest of the problems? Got me.
@"Jim Ewald" said:
No software updates, but we did upgrade the load balancer that sits in front of the web server yesterday afternoon. What you are describing sounds like that PC is using the old load balancer IP address.
My browser seems to time out very quickly. Is there anything I could try or you could change? Accessing the forum was fine for ages until yesterday.
That's more of a broken connection type message. One that the browser is still trying to restore long after its gone. Usually closing the tab and starting again works but maybe just reboot the whole computer to be sure. EDIT: And reboot the router or modem too.
How are you posting here at the moment? Is it via the same LAN/ISP connection?
I'm using an RPi connected to same router to post at the moment. Rebooting router did not help other PC, which has been switched off and on several times. A very recent change at the Parallax end is cause of problem.
Jim,
I just noticed I no longer can choose HTTP connection. I'm guessing the website now redirects to HTTPS only, right? I'm making a stab in the dark here as I don't know when this change was implemented. Very old browsers probably aren't capable of handling such a connection.
Relatedly, the login cookie doesn't have the Secure flag set, so it will happily let you continue your session over HTTP when you logged in over HTTPS, which is not good.
@evanh said:
Jim,
I just noticed I no longer can choose HTTP connection. I'm guessing the website now redirects to HTTPS only, right? I'm making a stab in the dark here as I don't know when this change was implemented. Very old browsers probably aren't capable of handling such a connection.
You are correct. Connections initiated on port 80 (HTTP) are received at the load balancer, which then then issues a HTTP 302 - Moved Permanently response and sends back a Location header with the new (correct) URL, https://forums.parallax.com:443/. You can see this with the curl utility. curl -I http://forums.parallax.com.
@Wuerfel_21 said:
HTTP works fine for me, so that's not it.
Relatedly, the login cookie doesn't have the Secure flag set, so it will happily let you continue your session over HTTP when you logged in over HTTPS, which is not good.
The Secure flag is set by the client browser. Modern browsers will set this cookie when connecting on a secure port (443) and leave it unset when connecting to port 80. The load balancer that sits on the other end of this connection does not examine this flag. All it cares about is what port the connection is on. If it's port 80, the LB issues a 301 redirect to https://forums.parallax.com. Otherwise, traffic on port 443 is passed on to the web server for further processing.
I just wanted to clarify that the browser is using either port 80 (HTTP) or port 443 (HTTPS) but it can't run an HTTP session within an HTTPS session. It doesn't work like that.
Secure Optional
Cookie is only sent to the server when a request is made with the https: scheme (except on localhost), and therefore is more resistant to man-in-the-middle attacks.
Note: Do not assume that Secure prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified with access to the client's hard disk, or from JavaScript if the HttpOnly cookie attribute is not set.
Note: Insecure sites (http:) can't set cookies with the Secure attribute (since Chrome 52 and Firefox 52). For Firefox, the https: requirements are ignored when the Secure attribute is set by localhost (since Firefox 75).
Yeah, just realized that the URL bar in my browser takes like a second to update on a redirect, it does indeed redirect to the HTTPS site. Though I think that will still send the login cookie unencrypted once when following a HTTP URL?
@Wuerfel_21 said:
Yeah, just realized that the URL bar in my browser takes like a second to update on a redirect, it does indeed redirect to the HTTPS site. Though I think that will still send the login cookie unencrypted once when following a HTTP URL?
Correct, any cookies sent by the browser over port 80 (HTTP) will be transmitted unencrypted. It the nature of the protocol. When port 443 (HTTPS) is used, the cookies are send after the SSL/TLS layer has been established, so they are encrypted at the point they are sent to the server.
@Wuerfel_21 said:
Yeah, just realized that the URL bar in my browser takes like a second to update on a redirect, it does indeed redirect to the HTTPS site. Though I think that will still send the login cookie unencrypted once when following a HTTP URL?
Correct, any cookies sent by the browser over port 80 (HTTP) will be transmitted unencrypted. It the nature of the protocol. When port 443 (HTTPS) is used, the cookies are send after the SSL/TLS layer has been established, so they are encrypted at the point they are sent to the server.
Setting Secure on the cookie would make that not happen.
@evanh said:
Jim,
I just noticed I no longer can choose HTTP connection. I'm guessing the website now redirects to HTTPS only, right? I'm making a stab in the dark here as I don't know when this change was implemented. Very old browsers probably aren't capable of handling such a connection.
You are correct. Connections initiated on port 80 (HTTP) are received at the load balancer, which then then issues a HTTP 302 - Moved Permanently response and sends back a Location header with the new (correct) URL, https://forums.parallax.com:443/. You can see this with the curl utility. curl -I http://forums.parallax.com.
Ah, don't have Curl installed. Figured wget would show me something:
Any chance the prior load balancer setup was maybe allowing plain HTTP traffic through? That would likely explain why Tony is stuck now, when he wasn't beforehand.
The previous load balancer was set up in 2014-2015 when the Forums supported both HTTP and HTTPS. That LB passed traffic on both ports so anyone still using HTTP would still be able to reach the web server.
While the new LB could still support HTTP, we are moving everything to use HTTPS with TLS 1.2 support in order to reduce attack vectors for bad actors.
I also want to correct a detail in my previous post. The LB is issuing a 301- Moved Permanently and not a 302 - Temporary Redirect.
@"Jim Ewald" said:
The previous load balancer was set up in 2014-2015 when the Forums supported both HTTP and HTTPS. That LB passed traffic on both ports so anyone still using HTTP would still be able to reach the web server.
While the new LB could still support HTTP, we are moving everything to use HTTPS with TLS 1.2 support in order to reduce attack vectors for bad actors.
I also want to correct a detail in my previous post. The LB is issuing a 301- Moved Permanently and not a 302 - Temporary Redirect.
I've never seen that happen before. From back when I first started using Chrome on Seven, the Forum would arrive using HTTPS, and then when I switched to this rig the same thing would happen.
The site has had a SSL/TLS certificate for years. Somewhere in the past few years, Chrome and - to a lesser extent - Firefox started defaulting to using HTTPS when one entered a web address in the address bar and did not specify the protocol. We are seeing in recent Chrome releases is a slow, steady constriction of what you can still do with HTTP. It's an endangered protocol.
Alas, Tony is using Win98, when not using a RPi, and, I presume, the newest web browser that still works with it. But that won't be new enough to work with up-to-date secure protocols.
Alas, Tony is using Win98, when not using a RPi, and, I presume, the newest web browser that still works with it. But that won't be new enough to work with up-to-date secure protocols.
Almost correct, my Windows PC runs Win98SE with KernelEx, which allows reliable use of Firefox 3.6.28 in XP mode. (It would be FF2.0.0.20 without KernelEx.) I had to reinstall 98SE when XP SP3 stopped booting (no discs available for the latter).
HTTPS + TLS 1.2 won't work for me but the new LB already doesn't, so it's the end of the road for accessing the Parallax forums with 98SE. Using the RPi is no great hardship with a KVM switch, however Chromium keeps telling me it can't be updated and needs to be reinstalled.
Comments
Three ticks with a CR
control V to paste
CR then tree more ticks
(see above)
Hello!
I did. I must be missing something. Doesn't the Markdown concept have tags for creating code boxes?
I looked at the referenced entity where the forum says, "You can use Markdown in your post." But all I saw were the methods that the text boxes uses for creating what I am typing. Even looking at an old post of mine didn't help, it was simply one that was translated by the gang behind you @Publison , to glom all of our older forum postings.
3 back ticks (```) IS the markdown tag for code blocks, at least in the github implementation:
https://guides.github.com/features/mastering-markdown/ (select code block in the example shown)
Hello!
I see your point. @VonSzarvas instead of using the Wikipedia definition of Markdown which does not go into enough detail why don't we use the Github explanation? I found exactly what @rosco_pc and even @Publison was getting at in there. Besides what you're thinking of as back ticks have a more complicated definition some place else.
Good question. I've made a note. Thanks.
New problem. I am finishing a commentary response to what @"Duane Degn" presented. And towards the end, the back end kept causing Chrome to put up its "Page Unresponsive" pop up. And naturally I was wondering what the <BLEEP!> the site was doing that kept causing that. I found it annoying that it kept interrupting me to do something else, and take very long to do it. I suspect that it was that strange lag that was earlier reported.
It's a buggy script, from the webpage, running in the browser. The browser is complaining that the script is taking too long to execute. The real problem is that javascript even exists.
Now there's an idea. In fact I agree. That scripting language should have been tossed aside. Depending on what the backend platform is for this site, I shall accept several, amongst them are PHP, and then the ASP stuff, and finally good old fashioned plain HTML.
TBH I second this...
Has the forum software been changed in the last 24 hours?
I can't access the forum now from my usual PC:
"The connection to the server was reset while the page was loading."
No software updates, but we did upgrade the load balancer that sits in front of the web server yesterday afternoon. What you are describing sounds like that PC is using the old load balancer IP address.
My browser seems to time out very quickly. Is there anything I could try or you could change? Accessing the forum was fine for ages until yesterday.
That's more of a broken connection type message. One that the browser is still trying to restore long after its gone. Usually closing the tab and starting again works but maybe just reboot the whole computer to be sure. EDIT: And reboot the router or modem too.
How are you posting here at the moment? Is it via the same LAN/ISP connection?
Hello!
It's quite possible that our friend back there did do all of that, which is why that post was successful. As to the rest of the problems? Got me.
I'm using an RPi connected to same router to post at the moment. Rebooting router did not help other PC, which has been switched off and on several times. A very recent change at the Parallax end is cause of problem.
Jim,
I just noticed I no longer can choose HTTP connection. I'm guessing the website now redirects to HTTPS only, right? I'm making a stab in the dark here as I don't know when this change was implemented. Very old browsers probably aren't capable of handling such a connection.
HTTP works fine for me, so that's not it.
Relatedly, the login cookie doesn't have the
Secureflag set, so it will happily let you continue your session over HTTP when you logged in over HTTPS, which is not good.Huh, Firefox can't be obeying its own settings then. I've got the "Don’t enable HTTPS-Only Mode" option checked.
You are correct. Connections initiated on port 80 (HTTP) are received at the load balancer, which then then issues a HTTP 302 - Moved Permanently response and sends back a Location header with the new (correct) URL, https://forums.parallax.com:443/. You can see this with the curl utility. curl -I http://forums.parallax.com .
The Secure flag is set by the client browser. Modern browsers will set this cookie when connecting on a secure port (443) and leave it unset when connecting to port 80. The load balancer that sits on the other end of this connection does not examine this flag. All it cares about is what port the connection is on. If it's port 80, the LB issues a 301 redirect to https://forums.parallax.com. Otherwise, traffic on port 443 is passed on to the web server for further processing.
I just wanted to clarify that the browser is using either port 80 (HTTP) or port 443 (HTTPS) but it can't run an HTTP session within an HTTPS session. It doesn't work like that.
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
Secure Optional
Cookie is only sent to the server when a request is made with the https: scheme (except on localhost), and therefore is more resistant to man-in-the-middle attacks.
Note: Do not assume that Secure prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified with access to the client's hard disk, or from JavaScript if the HttpOnly cookie attribute is not set.
Note: Insecure sites (http:) can't set cookies with the Secure attribute (since Chrome 52 and Firefox 52). For Firefox, the https: requirements are ignored when the Secure attribute is set by localhost (since Firefox 75).
Yeah, just realized that the URL bar in my browser takes like a second to update on a redirect, it does indeed redirect to the HTTPS site. Though I think that will still send the login cookie unencrypted once when following a HTTP URL?
Correct, any cookies sent by the browser over port 80 (HTTP) will be transmitted unencrypted. It the nature of the protocol. When port 443 (HTTPS) is used, the cookies are send after the SSL/TLS layer has been established, so they are encrypted at the point they are sent to the server.
Setting Secure on the cookie would make that not happen.
Ah, don't have Curl installed. Figured wget would show me something:
Yep
Any chance the prior load balancer setup was maybe allowing plain HTTP traffic through? That would likely explain why Tony is stuck now, when he wasn't beforehand.
The previous load balancer was set up in 2014-2015 when the Forums supported both HTTP and HTTPS. That LB passed traffic on both ports so anyone still using HTTP would still be able to reach the web server.
While the new LB could still support HTTP, we are moving everything to use HTTPS with TLS 1.2 support in order to reduce attack vectors for bad actors.
I also want to correct a detail in my previous post. The LB is issuing a 301- Moved Permanently and not a 302 - Temporary Redirect.
I've never seen that happen before. From back when I first started using Chrome on Seven, the Forum would arrive using HTTPS, and then when I switched to this rig the same thing would happen.
The site has had a SSL/TLS certificate for years. Somewhere in the past few years, Chrome and - to a lesser extent - Firefox started defaulting to using HTTPS when one entered a web address in the address bar and did not specify the protocol. We are seeing in recent Chrome releases is a slow, steady constriction of what you can still do with HTTP. It's an endangered protocol.
Thanks for the detailed info Jim.
Alas, Tony is using Win98, when not using a RPi, and, I presume, the newest web browser that still works with it. But that won't be new enough to work with up-to-date secure protocols.
Almost correct, my Windows PC runs Win98SE with KernelEx, which allows reliable use of Firefox 3.6.28 in XP mode. (It would be FF2.0.0.20 without KernelEx.) I had to reinstall 98SE when XP SP3 stopped booting (no discs available for the latter).
HTTPS + TLS 1.2 won't work for me but the new LB already doesn't, so it's the end of the road for accessing the Parallax forums with 98SE. Using the RPi is no great hardship with a KVM switch, however Chromium keeps telling me it can't be updated and needs to be reinstalled.
I just find it awesome that you are working with Windows 98SE in 2021!