No, really. Please, please, pretty please with sugar on top.

I frequently run into problems that developers either can’t figure out or had no idea existed, problems that stem from fundamentally not understanding HTTP.

For example, every few weeks I find myself evangelizing the Post-Redirect-Get pattern. Simplified, it goes like this:

  1. User submits form with POST (“buy this stuff!”).
  2. Server processes form, sends redirect to the browser to go to the results page.
  3. Browser requests results page with GET.
  4. Server sends results page.

One trick in doing this is that if you want to display a message about the transaction in step 2 on the page in step 3 (“you bought the stuff!”), you need to temporarily stuff that message into session then remove it when you’re done. Rails makes this easy by introducing the Flash, but it’s becoming more common in other frameworks, too.

Simple enough, and it solves all sorts of problems that I won’t get into now. But I still run into conceptual difficulties:

  • Maybe a developer thinks that the browser works directly with Java objects (or PHP, or C#…) and can just manipulate and share these with the server somehow in stateful way. Nope. HTTP is stateless, and your HTML form is just that: HTML.
  • It could be that a developer believes that the message can be sent back to the browser in the response in step 2 and be somehow available after the browser gets the HTML page in step 4. Um, no. Not the way you’re thinking.

The nitpicky and clever among you will point out that with trickery and by misunderstanding or misconstruing what I’m saying, it’s possible to do those things. For instance, you could use Ajax and DWR to communicate “directly” with Java objects from browser-based JavaScript. True… but not the point. It’s still not like the browser is a Java client communicating over RMI. Nothing like it. There’s a reason I put “directly” in quotes.

But how about that second example? You could stuff a message in a cookie in the response, and re-use that cookie in the results page. Right? Well, yes. Very good of you to notice.

Dreaming up these workarounds implies that you understand HTTP at least well enough to know its limitations and its mechanics. I’m not talking about you, I’m talking about people who just do not conceptually understand an HTTP transaction. And it’s not just at work, it’s not just among Java programmers, I encounter these issues all over the place and on all sorts of platforms.

I can’t really blame the developers, at least the junior ones. The APIs that we work with nowadays to write web apps remove us from the nitty-gritty of HTTP, just as we are removed from the pain of TCP/IP programming. That might be a good thing, but it leaves us with a leaky abstraction.

So what? So I’ve got a little pet peeve of a pattern. Big deal. What else is HTTP gonna get you?

Unless you have even a basic understanding of HTTP, there will be whole classes of vulnerabilities and design flaws in your web applications. You’ll have insecure session management, for starters, and probably cross-site request forgery bugs. I frequently encounter inadequately restricted URLs because of a misled belief that if a link to a page/resource isn’t exposed, that no one can get there.

Note that I wrote design flaws. These are not just developer problems, code-level vulnerabilities. Poor session management often starts with poor architecture and design. Misunderstanding the basic protocol behind the web can contribute to design problems that manifest in broken code.

How do you learn HTTP? Google around. The third chapter from the out-of-print Web Client Programming with Perl is a good start. If you like paper, I highly recommend Chris Shiflett’s HTTP Developer’s Handbook.

Here’s the trick: it’s not hard! Spend just a few minutes to understand the basics of HTTP. You’ll be a better developer, and your apps will be better for it.