Use the Right HTTP Method

This demonstration illustrates a subtle but common bug, in which a Web application uses HTTP GET, where HTTP POST is required. Usually, the implementor of the application has done this because it saves a step for users, and it's easier to code. This demonstration illustrates the serious problems that can result.

The wrong way: using HTTP GET to change the state of a resource

You are going to use the Web to subscribe to a magazine. The magazine publisher takes your name, which you supply on a form, and then sends you an email that asks you to click on a Web link to confirm you subscription. When you click on the "Confirm Subscription" link in the email, a database at the server is updated to record your subscription. If you already have a subscription, then the system will tell you that.

Unfortunately, because HTTP GET is defined as a safe operation, Web software may do the GET before you see the email and decide to confirm your subscription. For example, some browsers let you download pages for offline use, and search spiders to GET's on all the URI's they find.

Click here to order a subscription.

The right way: using HTTP GET to go to a page that will use POST

This time, there will be an extra step. When you follow the link to the email, no server-side state is changed. The confirmation page you see there uses POST to confirm your subscription. No Web software will assume that the POST can be done without consequence. This is the right way to use the Web: web caches, spiders, etc. will not accidently subscribe to the magazine for you!

Click here to order a subscription.