The invention of CGI was an innovation on the server side; it involved changing a fundamental assumption about servers and allowing the response to be dynamically generated instead of simply read in from a file.
HTTP tunneling is a similar innovation, which builds upon the idea of dynamic pages. It involves relaxing the assumption that the web server receives or returns valid HTML. The reasoning is simple: if the web server simply forwards certain requests to an arbitrary application, and if the response from that application is simply rerouted to the client by the web server (without the web server doing anything to the data it is sending), then there’s no particular requirement that the data be HTML. All of this infrastructure can be made to work with almost any data format.
In essence, HTTP tunneling involves using
the Web as a communications protocol for non-Web
applications. When you think about it, dynamic
classloading was our first tunneling application.
The request originated with an instance of
URLClassLoader,
not a web browser, and the response was the
bytecode for a class, not an HTML page.
HTTP tunneling is widely used for two reasons, both very pragmatic. First, it allows application developers to reuse many of the components and infrastructure that already exist for web applications, and to easily define an application protocol using these components.
Moreover, doing so enables application developers to easily incorporate multiple languages. Since almost ...
No credit card required