Understanding the HTTP Protocol (Part 3)

If you missed the previous articles in this series please go read:

HTTP the protocol

Well, over the course of the past two articles on HTTP that I have written, it is becoming clear that there is a fair amount to the HTTP protocol. It is certainly what I would term a “dense” protocol, simply due to the fact there is a lot to it. Much like DNS is a dense protocol due to its many resource records and the functions they fulfill. You may be thinking that “holy cow!” is there yet more to HTTP!?. Indeed there is, would be the answer, and  that is pretty neat if you ask me. Having protocols such as HTTP perform so many various tasks via its built in metrics, such as the ones we have already covered, is no small feat. Therefore my hat goes off to the developers of the HTTP protocol, in all of its revisions. They are the true talents without a doubt.

With that being said, just what else is there to cover. We shall approach some of the remaining parts of the HTTP protocol one piece at a time. Also as promised in part two, I shall quickly cover the usage of a HTTP proxy such as Spike proxy. This excellent tool was written by Dave Aitel, who also happens to be one of the premiere talents today in the world of network security.

What are status codes?

Like many protocols, HTTP works on the client/server model. Using this model, there logically would be a need to convey error conditions, as they are encountered during the session between the web client and web server. Makes sense doesn’t it? For if you did not have such status codes things could quickly get very messy. The status codes used by many application layer protocols are broken down into five broad categories, and are as follows;

Status code series 1xx
Status code series 2xx
Status code series 3xx
Status code series 4xx
Status code series 5xx



Each application layer protocol usually has specific error conditions assigned to the categories noted above. In our case they are as follows;

1xx Series

Code    100      Continue
Code    101      Switching protocols

2xx Series

Code    200      OK
Code    201      Created
Code    202      Accepted
Code    203      Non-authoritative


There are quite a few more as this goes up to the 500 series. They can all be found at this link. I hope you don’t cringe when you see that it is the actual RFC for HTTP. The definitive source for any protocol is always the RFC for it. Found there will be all of the nitty, gritty details that I enjoy reading.

Client requests and commands

Now we have covered the GET request as we saw in the packet which contained the web clients request to the web server, there are many more types that we can see a web client issue. Let’s cover them! Following is a list of potential web client requests or actions to a web server.

GET
The web client is requesting a resource that is on the web server

POST
This illustrates that the web client is sending information to the web server and is quite often used, when say, filling in an online form.

PUT
This occurs when a web client is sending a replacement document to the web server.

HEAD
You will see this when the web client wants some information about a resource on the server and is not requesting the resource itself.

DELETE
Well this one is pretty easy, and is used to delete a document from the web server.

TRACE
This one you won’t normally see, but is used when the web client wants the proxies to declare themselves. It is often used for debugging purposes.

OPTIONS
You will see this when the web client wants to know what other methods can be used for a document on the server.

CONNECT
Rounding out the various client methods is connect. This is used when a web client wants to connect to an HTTPS server via a proxy.

There are quite a few methods that a web client can use to chat with a web server as we can now see. That being said, you will normally only see the GET request and sometimes the HEAD if all you do is normal browsing. All of these are of use though if you are trying to perhaps debug a web application.

Someone stole my cookie!

It probably wasn’t the cookie monster either. There are quite a few misconceptions about cookies, as I alluded to earlier in this article series on HTTP. One of the biggest I find is just, what are they and what do they do? It always pays to be as educated as possible, and using that as my segue way lets discuss cookies!

Just what is a cookie anyways? Well, simply put, they are a plain text file that is stored on the client computer by the web server. This cookie is used to store session variables such as your username, password, amongst other information. Cookies themselves are not part of the HTTP protocol itself, but it is now pretty much considered synonymous with it. Some websites force you into accepting cookies for the website to function properly. So in some cases it is not wise to deny cookies completely as part of your security settings.

There are two types of cookies; the session cookie, which is only valid for the length of the browser connection to the website, and the persistent cookie, which will survive beyond the session termination. It is important to realize, as I mentioned before that a cookie is not an executable. That being said the cookies themselves should ideally be encrypted, so as to negate casual dissection of them.

Using Spike proxy

I mentioned earlier that one way of furthering your knowledge of HTTP is to use a tool such as Spike proxy. What this tool will allow you to do is intercept your web client requests, and modify them. You don’t want to be doing this against a real web server, or else the owners might get irate with you! What I suggest is that you simply download a version of Apache, and install it on a computer at your home. Please be aware though that you will need a JRE on your computer to use Spike Proxy. Once this is done you are free to now invoke Spike Proxy, and start modifying your HTTP requests to see how your Apache web server will react to it.

Final thoughts

Being involved in the computer network industry, in whatever form that might take, means that you must constantly be upgrading your skills. Whether that means learning the new Windows web server, or further developing your knowledge of a specific protocol. The underlying theme is that you must set aside some time to constantly seek out new information to learn. Staying still in this industry does not bode well for one’s longevity in it. I sincerely hope that this article series was of interest to you. As always I welcome your feedback, both good and bad. Till next time!

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top