Introduction

Your Web server thinks that your URL should be redirected to another URL - the 'proxy'. This is very often related to security considerations governing access to URL resources.

305 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 your Web server:

• Obtain an IP address from the IP name of your site (your 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 your 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 '305'.

Resolving 305 errors - general

The 305 response from your Web server should always include an alternative URL to which redirection should occur. If it does, a Web browser will immediately retry the alternative URL. So you never actually see a 305 error in a Web browser, unless perhaps you have a corrupt redirection chain e.g. URL A redirects to URL B which in turn redirects back to URL A. If your client is not a Web browser, it should behave in the same way as a Web browser i.e. immediately retry the alternative URL.

If the Web server does not return an alternative URL with the 305 response, then either the Web server sofware itself is defective or your Webmaster has not set up the URL redirection correctly.

Resolving 305 errors - CheckUpDown

Redirection of URLs may occur for low-level URLs (specific URLs within your Web site such as www.isp.com/products/index.html) when you reorganise your web site, but is relatively uncommon for the top-level URLs (such as www.isp.com) which most CheckUpDown users ask us to monitor. So this error should be fairly infrequent.

You first need to check that the IP name you specified on your CheckUpDown account is accurate. If you or your ISP have configured something so that any access using this name should now be redirected to another name, then you need to update your account to start using the new name.

If you believe that the IP name we use is exact (should not be redirected), please try accessing the current URL using a Web browser. Note carefully which URL actually gets displayed, because your browser may silently switch to a substitute URL if it receives an 305 message from your Web server. If you see any evidence of a new URL, try accessing that directly from your browser. If this works (you see your Web site as expected), then this new URL is what you may need to update on your CheckUpDown account.

If none of the above help, we can analyse the underlying HTTP data streams we receive from your Web server. These can provide additional information about the proxy URL(s) which your Web server thinks we should be accessing. Before doing this, we prefer you to identify any deliberate changes on your side, liaising with your ISP if needs be.

305 errors should occur infrequently, because top-level URLs do not change often. If they do change, then this is typically because a redirection URL is being suggested. This pervasive change is unlikely to occur by accident, so most often you can resolve this error by updating your CheckUpDown account following a deliberate change of URL on your part.

The most important thing is to identify the proxy URL and establish whether the redirection to that proxy is actually what you want.