A couple of months ago, one of the developers I work with asked me to test a bug fix he’d done. In order to test it, I’d need to make an HTTP request with the OPTIONS method. I’d never heard of the OPTIONS method, and it got me thinking: what other HTTP methods did I not know about? In this post, I’ll talk about four rarely used methods and and how you might use them in your testing.
OPTIONS:
This method returns whatever methods are allowed for a particular endpoint. For example, if you had a URL called http://cats.com/cat, and you could use it to get a list of cats or add a cat, the methods that the OPTIONS request would return would be GET and POST.
OPTIONS demo:
Let’s use the Restful-Booker API to try out the OPTIONS method. Assuming you have Postman installed, we’ll create a new GET request that calls this URL: https://restful-booker.herokuapp.com/booking. When you run this request, you’ll see a list of all the available hotel-bookings for the app in the response body. Now let’s change the method from GET to OPTIONS. When you run this request, you’ll see GET, HEAD, and POST in the response body. These are the three methods that are available for this endpoint.
Why would you use the OPTIONS method?
If you are testing an API, this is a great way to find out if there are any valid endpoints that you don’t know about. This can reveal more features for you to test, or it could potentially reveal a security hole. For example, maybe your API shouldn’t really have a DELETE method, but someone implemented it by mistake.
HEAD:
This method returns only the headers of the response to a GET request. It’s used if you want to check the response headers without putting pressure on the server to return other data.
HEAD demo:
We’ll use the very same URL that we used for our OPTIONS demo. First, let’s return our method to GET. Run the request, and see that you get a response body with the list of available bookings. Take a look at the headers that were returned with the response: Server, Connection, X-Powered-By, Content-Type, Content-Length, Etag, Date, and Via. Now let’s change our verb to HEAD and re-run the request. We won’t get anything in the body of the response, but we will get those same eight headers.
Why would you use the HEAD method?
This method would be a great way to check the headers of a GET response without having to actually return data. Headers are important because they often help to enforce security rules. If you know what headers your API should be returning, you can run this request on all of your endpoints to make sure that the right headers are being used.
CONNECT:
This method establishes a tunnel to the server that is identified by a URL. It’s often used for proxy connections.
CONNECT demo:
For this demo, you’ll need to have curl enabled. You can check to see if curl is installed on your machine by typing curl –version in your command line window. If you get a version back, you have curl installed.
To try out CONNECT, type this command into your command line window: curl -v CONNECT http:///kristinjackvony.com. Take a look at the response you get; about nine lines from the bottom, you’ll see the message “301 Moved Permanently”. This is because I recently changed this domain name to point to my Thinking Tester webpage instead of my personal webpage. I didn’t do that because of this tutorial, but it wound up being useful!
Why would you use CONNECT?
You’d use CONNECT any time you want to see exactly what happens when you try connecting to an HTTP resource. This could be helpful with security testing, and any time you are using a proxy.
TRACE:
This method is similar to CONNECT in that it connects to a resource, but it also tries to get a response back.
TRACE demo:
We’ll use curl again to try out TRACE. Type this command in the command window: curl -v TRACE http://isithalloween.com. You’ll get back some response headers, plus the source code for the page.
Why would you use TRACE?
This would be good for security testing. Because you get the source code for the page in the response, you can inspect it to see if there are any cookies or authentication headers that a malicious user could exploit.
I hope you’ve gotten some good testing ideas from these rarely used HTTP methods! In my research I found all kinds of other methods that appear to no longer be in use, such as COPY, LINK, UNLINK, LOCK, and UNLOCK. Have you ever used these, or other rare methods? Tell me about it in the comments!