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.
Justin James is an OutSystems MVP, architect, and developer with expertise in SaaS applications and enterprise applications.