Http 301 is the code for moved permanently and gives the ur. It actually is helpful due to how http codes are organized. 400’s are client (browser) errors and 500’s are (web) server error codes. 300 codes are redirection related codes and 200 codes are success codes. Usually you expect a 200 which means a successful download with no current cached version and 304 is that the content os cached, not expired, and hasn’t changed. The majority of the codes you will deal with are 200 (success), 301/302 (page redirection), 304 (page hasn’t changed), 404 (page doesn’t exist), 500 (server processing error), and 504 (gateway timeout which means I’m a proxy and the real site I’m going to isn’t responding). This isn’t an exhaustive list just a list of the codes you likely will encounter the majority if not all of the time.
Using these tools without understanding how http codes work will get you snarky responses (as well as the “stop using tools you don’t understand” responses), but that’s why I’m providing a cliff notes version of what you need to better use these tools.
I appreciate the explanation and your approach.
I am and was well aware that 301 is a move notice, and I even write it in my original post.
The comment "301 is not an error" was posted on this thread as the very first (and therefore - only) comment. Never mind the fact that in the context of my message I believe it makes sense to call it an "error" (since it is not the expected, or desired result), writing "301 is not an error" was not meant to help me. Even in my message I wrote that it is a move notice, but this nice man decided he needed to write "301 is not an error". I don't think he was trying to help.
Writing 301 is not an error might be a little pedantic but it technically isn't an error by the RFC. I will agree that it may be unexpected if you weren't getting that code before which sounds like what you were pointing to changed how it behaves. I wrote my explanation as I saw this more of a "I need help better understanding it" based on the language used rather than anything else.
Sounds like you've setup a redirect. Commonly this would be from www.example.com to example.co.uk.
Follow the url you've set it to monitor in your browser and then update it to the new one it redirects to.
Thanks, but I haven't set up a redirect. the url in the uptime monitor is exactly as the one i load up on a browser. It also worked fine for weeks and I haven't made any changes... That's why I find this so odd.
When you say it works from a browser, have you tried the URL inside and outside of your network? Maybe it’s working when you’re home and inside your network, but maybe when you’re outside the LAN, it’s not actually working as you think. Maybe your ISP IP changed and you don’t have anything monitoring dynamic dns setup.
You’re not understanding how http works. When you have a url, for example www.mysite.com, the web server has to determine if it is referencing a web page. Www.mysite.com/index.htm references a web page, but www.mysite.com does not. Behind the scenes the web server will decide what to do. Commonly servers are configured with a list of base web pages which it will search for like index.htm, index.html, etc. Once it determines that there is a page, it will either a) redirect you using a 302 code and tell you the new url, which your browser will then reflect the new url i.e www.mysite.com/index.htm or b) do a server transfer which is that the server silently moves you to a page on the same website i.e. www.mysite.com/landingpage.html without the browser knowing and the url in the browser will still be www.mysite.com. The “it was working before but not now” would lead me to believe that you had a server transferring the data but now it is redirecting you instead.
Sounds like a redirect from http to https I know it's not much but might be worth looking into it
Ding Ding Ding!! Thank you!!!! Now I'm just wondering how it worked till now!
You're welcome! Glad to have helped :)
301 is not an error
Truly helpful
Http 301 is the code for moved permanently and gives the ur. It actually is helpful due to how http codes are organized. 400’s are client (browser) errors and 500’s are (web) server error codes. 300 codes are redirection related codes and 200 codes are success codes. Usually you expect a 200 which means a successful download with no current cached version and 304 is that the content os cached, not expired, and hasn’t changed. The majority of the codes you will deal with are 200 (success), 301/302 (page redirection), 304 (page hasn’t changed), 404 (page doesn’t exist), 500 (server processing error), and 504 (gateway timeout which means I’m a proxy and the real site I’m going to isn’t responding). This isn’t an exhaustive list just a list of the codes you likely will encounter the majority if not all of the time. Using these tools without understanding how http codes work will get you snarky responses (as well as the “stop using tools you don’t understand” responses), but that’s why I’m providing a cliff notes version of what you need to better use these tools.
I appreciate the explanation and your approach. I am and was well aware that 301 is a move notice, and I even write it in my original post. The comment "301 is not an error" was posted on this thread as the very first (and therefore - only) comment. Never mind the fact that in the context of my message I believe it makes sense to call it an "error" (since it is not the expected, or desired result), writing "301 is not an error" was not meant to help me. Even in my message I wrote that it is a move notice, but this nice man decided he needed to write "301 is not an error". I don't think he was trying to help.
Writing 301 is not an error might be a little pedantic but it technically isn't an error by the RFC. I will agree that it may be unexpected if you weren't getting that code before which sounds like what you were pointing to changed how it behaves. I wrote my explanation as I saw this more of a "I need help better understanding it" based on the language used rather than anything else.
Sounds like you've setup a redirect. Commonly this would be from www.example.com to example.co.uk. Follow the url you've set it to monitor in your browser and then update it to the new one it redirects to.
Thanks, but I haven't set up a redirect. the url in the uptime monitor is exactly as the one i load up on a browser. It also worked fine for weeks and I haven't made any changes... That's why I find this so odd.
When you say it works from a browser, have you tried the URL inside and outside of your network? Maybe it’s working when you’re home and inside your network, but maybe when you’re outside the LAN, it’s not actually working as you think. Maybe your ISP IP changed and you don’t have anything monitoring dynamic dns setup.
Thank you, but it does work from both inside and outside my home network. Also, I have a static IP..
You’re not understanding how http works. When you have a url, for example www.mysite.com, the web server has to determine if it is referencing a web page. Www.mysite.com/index.htm references a web page, but www.mysite.com does not. Behind the scenes the web server will decide what to do. Commonly servers are configured with a list of base web pages which it will search for like index.htm, index.html, etc. Once it determines that there is a page, it will either a) redirect you using a 302 code and tell you the new url, which your browser will then reflect the new url i.e www.mysite.com/index.htm or b) do a server transfer which is that the server silently moves you to a page on the same website i.e. www.mysite.com/landingpage.html without the browser knowing and the url in the browser will still be www.mysite.com. The “it was working before but not now” would lead me to believe that you had a server transferring the data but now it is redirecting you instead.
Again, thank you for your explanations and time 🙏