Fighting For the Open Web

The Internet Is Built On Abstraction The open web has come a long way. It's done so specifically through the power of abstraction, an engineer's best friend. The Internet itself, platform, protocol and methodologies, hasn't drastically changed in 10+ years. We're sill using HTML 4 with CSS 1, 2 and an unholy amount of CSS-P. JavaScript is slowly evolving, but not usefully: nothing in a modern browser looks like the insanely quick, high level language JScript.NET was in 2001, or the similarly powerful ActionScript variants found in modern Flash virtual machines. If the Internet marks its progress, it has to do so in abstractions.

JavaScript frameworks are ever evolving, providing increasingly powerful options. Some - like YUI or Dojo - are tiny kernels or frameworks in of themselves. These frameworks provide layers of insulation from the raw mechanics of the JavaScript and HTML engine in a browser. Coupled with increasingly powerful, component-oriented frameworks like Tapestry, Wicket, Echo and JSF (which themselves re-imagine the request/response mechanics of the server side as an event driven, component oriented UI), we've managed to elevate the state of the art to stunning zeniths.

These abstractions are enabling features, and they are the platform, not the internet. To listen to the vendors building these components for us (PARLEYS) you see that people are excited. I'm inclined to share their zeal, and I have no doubt of the promises of tomorrow. Though I see the progress, I can't help but feel that our biggest enemy in progress continues to be our past. Our abstractions "leak," as all of sufficient complexity ultimately do.

Why This Matters A colleague, Arin, and I were working on a project using JBoss Seam, easily one of the more advanced JSF based stacks. Seam is powerful, principally because of abstraction: JSF itself hasn't changed in years, nor has EJB. Few would deny that Seam is much more than the sum of its parts, however. In JBoss Seam it's easy to manipulate JBoss RichFaces components, which make it so unspeakably easy to use Ajax that you might forget how much of a hack Ajax was and - to an extent - remains. This is the hallmark of a truly great abstraction.

Sometimes abstractions deny the user an understanding of the risks involved. Sometimes they "leak." (SPOLSKY) This happened recently to a colleague of mine, Arin. In the code, a JBoss RichFaces component, an a4j:commandLink was being used to trigger some functionality on the server and subsequently issue a redirect. Incredibly, all of this works consistantly across most modern browsers, most of the time.

Internet Explorer has strict rules (sometimes bordering on the edge of irrelevance) regarding promotion of security zones. It will not propagate certain headers or allow certain actions when going from one type of zone to another. Particular to our situation was the REFERRER header, which tells the reader the page from whence the user's come. The commonly known case is that if you issue a call from a sub-domain that's different than the one to which the call is being made, you'll face restrictions. If you call from an secured HTTPS resource to a non secure HTTP resource, you'll face restrictions. Notably: if you issue a redirect stemming from JavaScript function, you'll face restrictions. This is the bug that bit us.

As to the resolution... well we would love to find out! There is no easy answer. We ended up using rearchitecting the sequence. We used the action URL from the FacesContext and - using the view id of the page that had the RichFaces a4j:commandLink - passing the URL to Flash itself. The internet's an important, and widely used communications tool and technology in general. It deserves better.

This was a pretty critical code path that's been highly tested, and the REFERRER header is the norm for the Internet. This works well in all other browsers we tested. It's exclusively broken in Internet Explorer, whose code bases are years old. It is breaking the internet because it is breaking the abstractions. You would think that in the profliferation of patches coming out of Redmond would be small upgrades fixing these sorts of things. We don't always need a flashy new upgrade that's inadequate at best, irrelevant at worst. Surely, most people would settle for a working browser - evolved in small steps, not leaps. If Internet Explorer and other vendors are going to participate in the evolution of the internet, then they need to do so by enabling abstractions in addition to enabling the large movements, or at the very least have the dignity to leave it to the Flashes and JavaFX's of the world.

References

1. SPOLSKY: Leaky Abstractions
2. PARLEYS: Visit Parleys.com, search: "Ajax for Everyone - Building better Rich Internet Applications faster with JSF"