Introduction

The HTTP protocol defines methods to indicate the action to be performed on the Web server for the particular URL resource identified by the client (e.g. your Web browser or our CheckUpDown robot). The methods are as follows:

• OPTIONS: Find out the communication options available for a particular URL resource. Allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without a specific action involving transfer of data.
• GET: Retrieve the information identified by the URL resource e.g. GET a particular Web page or image. The most common method by far.
• HEAD: Identical to GET except that the server returns header information only, not the actual information identified by the URL resource. Useful to obtain metainformation about the entity implied by the request without transferring the entity-body itself. Often used to test hypertext links for validity, accessibility, and recent modification.
• POST: Submit data to the Web server such as 1) post a message to a bulletin board, newsgroup or mailing list, 2) provide input data - typically from a CGI form - to a data-handling process, 3) add a record directly to a database.
• PUT: Set (place/replace) the data for a particular URL to the new data submitted by the client. For example, upload a new Web page to a server.
• DELETE: Remove the data associated with the URL resource. For example, delete a Web page.
• TRACE: Run a remote, application-layer loop-back of the request message. Effectively a 'ping' which tests what data the Web server is receiving from the client.
• CONNECT: Reserved for use with tunneling (e.g. SSL) via a proxy server. This method is defined only for HTTP version 1.1, not the earlier version 1.0.

All Web servers can be configured to allow or disallow any method. For example if a Web server is 'read-only' (no client can modify URL resources on the Web server), then it could be set up to disallow the PUT and DELETE methods. Similarly if there is no user input (all the Web pages are static), then the POST method could be disallowed. So 405 errors can arise because the Web server is not configured to take data from the client at all. They can also arise if the client does not have sufficient authority to the particular URL resource identified on the request.

405 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 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 '405'.

Resolving 405 errors - general

405 errors often arise with the POST method. You may be trying to introduce some kind of input form on your Web site, but not all ISPs allow the POST method necessary to process the form.

All 405 errors can be traced to configuration of the Web server and security governing access to the content of the Web site, so should easily be explained by your ISP.

Resolving 405 errors - CheckUpDown

This error should simply never occur on your CheckUpDown account. If it does, it typically indicates defective programming of our systems or of the Web server which manages your site. We use the GET method only, which all Web servers should allow (otherwise no-one would ever be able to see your Web site).

Please contact us (email preferred) whenever you encounter 405 errors - there is nothing you can do to sort them out. We then have to liaise with your ISP and the vendor of your Web server software to agree the exact reason for the error.