ThyroidHelp Forum for discussions of underactive thyroid, hashimoto's thyroiditis, grave's disease and adrenals FAQ

Here you can find answers to questions about how the board works. Use the links or search box below to find your way around.

400 Bad Request

Introduction

The Web server (running the Web site) thinks that the data stream sent by the client (e.g. your Web browser or our robot was 'malformed' i.e. did not respect the HTTP protocol completely. So the Web server was unable to understand the request and process it.

400 errors in the HTTP cycle

Any client (e.g. your Web browser or our robot goes through the following cycle:

  • Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code it recognises as '400'.

Fixing 400 errors - general

There is a low-level problem in the client or the Web server or both. 95% of the time this is because of a problem on the client system e.g. there is something unstable on your PC running the Web browser.

  • Is your PC secure ?. If your PC is not well-protected, then all kinds of problems may occur - including HTTP 400 errors. If you run Windows, stay uptodate with automatic security updates from Microsoft and possibly consider getting a registry cleaner. Always have good anti-virus and spyware protection. Invest in a hardware firewall if you can afford one. Be sensible surfing the Web - block pop-up windows and avoid bad sites. If your PC security is compromised, then Web traffic out from your PC to the Internet may be secretly corrupted by malware (spyware, viruses, etc.) running on your PC. This can be difficult for you to detect.
  • Have you installed web-based software ?. Some social networking and games sites ask you to download and run software on your PC so you can interact with other people on the Internet directly (without using your Web browser). This software, if badly written or even criminal, can corrupt all HTTP traffic from your PC. Getting rid of that defective software can be difficult. At worst you may have to reinstall your operating system again (possibly losing all your personal data on your PC if you do not have backup).
  • How stable is your Internet connection ?. If you have recently changed ISPs or your ISP is very slow or unreliable, then Web traffic from your PC out to any site on the Internet may be corrupt. Your ISP may have reconfigured some of their setup (e.g. introduced new proxy servers or cacheing) that is causing some instability. A possible sign of problems here is if you can not easily browse the Web site of your ISP. You can also try to check that the Web site you are actually visiting is the one you think you are visiting. For example, you may have a DNS problem. You can check this using a ‘ping’ test. A DNS problem may be caused by your ISP or may be on your own system e.g. in a ‘hosts’ file.
  • Do you get the error on more than one Web site ?. If you get the error on lots of Web sites, this indicates the problem is on your PC, not on those sites.
  • Do you get the error using more than one browser ?. If you have two or more Web browsers installed on your PC and the behaviour is not the same (one Web browser gives an HTTP 400 error visiting a site, another Web browser does not give the 400 error visiting the same site), then one of your browsers may be defective. Try to find an upgrade or security fix for the problem browser. If you recently changed some configuration options in the problem browser, try reversing the change to see if that helps.
  • Do you get the error on big Web sites ?. If you get the problem on quite a small site, visit some of the bigger sites like Amazon, Ebay, Google, Microsoft and Yahoo. If you get the problem only on small sites, it indicates a problem with only those sites or the traffic from your PC to those sites.
  • Do you get the error on simple URLs ?. If you get a problem with a long complicated URL (such as http://www.xxx.com?PHPrequest=643&value=dres&cookies=No) but not with a shorter simpler URL for the same site (such as http://www.xxx.com), this can indicate a problem with the Web server on the site you are trying to visit. This is not conclusive evidence, but is a good starting point. Contact the owners of the Web site and describe the problem to them. You may find for example the problem occurs with POST methods (you are both submitting data to the Web site and retrieving data from the Web site), but not with GET methods (you are only retrieving data from the Web site).
  • Do you have a cache problem ?. Try clearing your cookies, browser cache and browsing history in your Web browser. Disable or remove any third-party cacheing or ‘web accelerator’ software you installed. Then try rebooting your PC and any firewall/router you use to connect to the Internet. That may not fix the error, but at least may eliminate any problem due to old settings on your PC.
  • What has changed since you started getting the HTTP 400 problem ?. In general terms, think about what has changed on your PC since you first started seeing the problem. This may cover any of the items mentioned above. Work backwards and see if undoing those changes makes any difference.

So there are a lot of things that you can check on your own PC. If you contact the owners of the Web site giving you the HTTP 400 error and they say "We have lots of other users who do not have your problem - so there must be something wrong with your PC", they are right most of the time - and you can not expect them to be interested in fixing your own PC problems. However if they know there is a problem with their Web site, they should hopefully tell you so and tell you when they plan to fix the problem.

401 Unauthorized

Introduction

The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our CheckUpDown robot) was correct, but access to the URL resource requires user authentication 1) which has not yet been provided or 2) which has been provided but failed authorization tests. This is commonly known as "HTTP Basic Authentication". The actual authentication request expected from the client is defined in the HTTP protocol as the WWW-Authenticate header field.

Generally this error message means you need to log on (enter a valid user ID and password) somewhere first. If you have just entered these and then immediately see a 401 error, it means that one or both of your user ID and password were invalid for whatever reason (entered incorrectly, user ID suspended etc.).

401 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle:

  • Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code it recognises as '401'.

Fixing 401 errors - general

Each Web Server manages user authentication in its own way. A security officer (e.g. a Web Master) at the site typically decides which users are allowed to access the URL. This person then uses Web server software to set up those users and their passwords. So if you need to access the URL (or you forgot your user ID or password), only the security officer at that site can help you. Refer any security issues direct to them.

If you think that the URL Web page *should* be accessible to all and sundry on the Internet, then a 401 message indicates a deeper problem. The first thing you can do is check your URL via a Web browser. This browser should be running on a computer to which you have never previously identified yourself in any way, and you should avoid authentication (passwords etc.) that you have used previously. Ideally all this should be done over a completely different Internet connection to any you have used before (e.g. a different ISP dial-up connection). In short, you are trying to get the same behaviour a total stranger would get if they surfed the Internet to the Web page.

If this type of browser check indicates no authority problems, then it is possible that the Web server (or surrounding systems) have been configured to disallow certain patterns of HTTP traffic. In other words, HTTP communication from a well-known Web browser is allowed, but automated communication from other systems is rejected with an 401 error code. This is unusual, but may indicate a very defensive security policy around the Web server.

403 Forbidden

Introduction

The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our robot was correct, but access to the resource identified by the URL is forbidden for some reason.

This indicates a fundamental access problem, which may be difficult to resolve because the HTTP protocol allows the Web server to give this response without providing any reason at all. So the 403 error is equivalent to a blanket 'NO' by the Web server - with no further discussion allowed.

By far the most common reason for this error is that directory browsing is forbidden for the Web site. Most Web sites want you to navigate using the URLs in the Web pages for that site. They do not often allow you to browse the file directory structure of the site.

This URL should fail with a 403 error saying "Forbidden: You don't have permission to access /accounts/grpb/B1394343/ on this server". This is because our CheckUpDown Web site deliberately does not want you to browse directories - you have to navigate from one specific Web page to another using the hyperlinks in those Web pages. This is true for most Web sites on the Internet - their Web server has "Allow directory browsing" set OFF.

403 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle:

  • Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code that it recognises as '403'.

Fixing 403 errors - general

You first need to confirm if you have encountered a "No directory browsing" problem. You can see this if the URL ends in a slash '/' rather than the name of a specific Web page (e.g. .htm or .html). If this is your problem, then you have no option but to access individual Web pages for that Web site directly.

It is possible that there should be some content in the directory, but there is none there yet. For example if your ISP offers a 'Home Page' then you need to provide some content - usually HTML files - for the Home Page directory that your ISP assigns to you. Until the content is there, anyone trying to access your Home Page could encounter a 403 error. The solution is to upload the missing content - directly yourself or by providing it to your ISP. Once the content is in the directory, it also needs to be authorised for public access via the Internet. Your ISP should do this as a matter of course - if they do not, then they have missed a no-brainer step.

If the entire Web site is actually secured in some way (is not open at all to casual Internet users), then an 401 - Not authorized message could be expected. It is possible, but unlikely, that the Web server issues an 403 message instead.

Some Web servers may also issue an 403 error if they at one time hosted the site, but now no longer do so and can not or will not provide a redirection to a new URL. In this case it is not unusual for the 403 error to be returned instead of a more helpful error. So if you have recently changed any aspect of the Web site setup (e.g. switched ISPs), then a 403 message is a possibility. Obviously this message should disappear in time - typically within a week or two - as the Internet catches up with whatever change you have made.

If you think that the Web URL *should* be accessible to all and sundry on the Internet and you have not recently changed anything fundamental in the Web site setup, then an 403 message indicates a deeper problem. The first thing you can do is check the URL via a Web browser. This browser should be running on a computer to which you have never previously identified yourself in any way, and you should avoid authentication (passwords etc.) that you have used previously. Ideally all this should be done over a completely different Internet connection to any you have used before (e.g. a different ISP dial-up connection). In short, you are trying to get the same behaviour a total stranger would get if they surfed the Internet to the Web page URL.

If this type of browser check indicates no authority problems, then it is possible that the Web server (or surrounding systems) have been configured to disallow certain patterns of HTTP traffic. In other words, HTTP communication from a well-known Web browser is allowed, but automated communication from other systems is rejected with an 403 error code. This is unusual, but may indicate a very defensive security policy around the Web server.

404 Not Found

Introduction

The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our robot was correct, but simply can not provide the access to the resource specified by your URL. This is equivalent to the 'return to sender - address unknown' response for conventional postal mail services.

404 errors in the HTTP cycle

Any client (e.g. your Web browser or our robot goes through the following cycle:

  • Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code that it recognises as '404'.

Fixing 404 errors - general

For top level URLs (such as www.isp.com), the first possibility is that the request for the site URL has been directed to a Web server that thinks it never had any pages for the Web site. This is possible if DNS entries are fundamentally corrupt, or if the Web server has corrupt internal records. The second possibility is that the Web server once hosted the Web site, but now no longer does so and can not or will not provide a redirection to another computer which now hosts the site. If the site is completely dead - now effectively nowhere to be found on the Internet - then the 404 message makes sense. However if the site has recently moved, then an 404 message may also be triggered. This is also a DNS issue, because the old Web server should no longer be accessed at all - as soon as global DNS entries are updated, only the new Web server should be accessed.

For low-level URLs (such as www.isp.com/products/list.html), this error can indicate a broken link. You can see this easily by trying the URL in a Web browser. Most browsers give a very clear '404 - Not Found' message.

Provided that the Web site is still to be found somewhere on the Internet, 404 errors should be rare. For top level URLs, they typically occur only when there is some change to how the site is hosted and accessed, and even these typically disappear within a week or two once the Internet catches up with the changes that have been made. For low-level URLs, the solution is almost always to fix the Web pages so that the broken hypertext link is corrected.

500 Internal Server Error

Introduction

The Web server (running the Web Site) encountered an unexpected condition that prevented it from fulfilling the request by the client (e.g. your Web browser or our CheckUpDown robot) for access to the requested URL.

This is a 'catch-all' error generated by the Web server. Basically something has gone wrong, but the server can not be more specific about the error condition in its response to the client. In addition to the 500 error notified back to the client, the Web server should generate some kind of internal error log which gives more details of what went wrong. It is up to the operators of the Web server site to locate and analyse these logs.

500 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:

  • Obtain an IP address from the IP name of the site (the site URL without the leading 'http://'). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'.

Fixing 500 errors - general

This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.

Search FAQ

Select this option if you would like your search to look in the text of FAQ items as well as their titles.

Select an option here to specify how you would like your search query to be treated. 'Any words' will return the most numerous but possibly least relevant results, while 'Complete phrase' will return only results that contain exactly what you are searching for.

Powered by vBulletin™ Version 4.2.4
Copyright © 2021 vBulletin Solutions, Inc. All rights reserved.
All times are GMT. The time now is 09:56 PM.