Apps

Structure of an HTTP response

Developers who could use some help understanding their HTTP debugger's logs should learn about HTTP requests and HTTP responses. Justin James provides an overview of HTTP responses.

Last week, we looked inside an HTTP request to see what makes them tick. This week, we will examine the data that comes back as the HTTP response. Like last time, we are looking at RFC 2616 for full details.

Just as the HTTP request started with a request line to indicate the most basic information, the HTTP response begins with a status line. The status line informs the consumer of the HTTP version in use, a status code (such as 404 or 200), and a reason explaining the code. The first digit of the code indicates the class of the status. To quote from the spec:

  • 1xx: Informational - Request received, continuing process
  • 2xx: Success - The action was successfully received, understood, and accepted
  • 3xx: Redirection - Further action must be taken in order to complete the request
  • 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
  • 5xx: Server Error - The server failed to fulfill an apparently valid request

For full details on each status code, see section 6.1 of the HTTP spec.

After the status line are the general headers, the response header, and the entity headers, followed by the message body. Other than the response header, I went into the details of these headers in my column Structure of an HTTP request.

The response headers contain information specific to the needs of the response, such as the location (used to redirect the client to a new URI). One of the more important response headers is WWW-Authenticate used in conjunction with status 401 (unauthorized). This is how web sites are able to prompt for usernames and passwords without using any backend processing logic (a browser user sees the browser prompting for a username and a password). This uses a challenge/response system. RFC 2617 outlines two methods for this authentication: basic (which uses cleartext usernames and passwords) and digest (which uses MD5 hashes). If you really want an exercise in learning the basics, it is a fun project to write your own implementation of HTTP authentication without using any libraries, just text processing and basic math to recreate the MD5 algorithm. I did this a long time ago in Perl, and working on that project was how I learned the guts of HTTP so well.

There isn't more to it than this for the typical usage scenarios. Fortunately, much of what you need to know is shared between the request and the response. Now that you understand HTTP requests and HTTP responses better, it will be a lot easier to understand your HTTP debugger's logs.

J.Ja

About

Justin James is the Lead Architect for Conigent.

2 comments
robo_dev
robo_dev

It's important for any developer to understand how http works, and more importantly how to ensure that input is sanitized and validated. I do a lot of web app vuln testing with tools such as TamperData and WebScarab, and it's scary sometimes how developers will 'assume' that the app is secure because they have, in effect. put a strong lock on the front door with good authentication, while a simple attack technique like http verb tampering will simply let anybody get inside their web application.

Justin James
Justin James

I know a lot of folks were disappointed with the lack of examples in the previous HTTP article. These were written as a pair and submitted as a pair, and due to some life circumstances, I did not have the chance to go back and add the samples like I normally would have done after the criticism on the first article. Please accept my apologies! J.Ja