CTO Articles
IT World
XML IN PRACTICE --- September 05 2002
The Rise and Fall of HTTP
By Sean Mc Grath
Someone (Mark Twain?) said "To a man with a hammer, everything looks like a nail".
Lots of people now have XML shaped hammers out there. I get the sense that some of them are tapping those hammers into the palms of their hands, contemplating swinging in the direction of the HTTP protocol.
I don't know how I feel about it yet. I'm just like that rabbit, caught in the headlights of the oncoming juggernaut. I'm too engrossed in observing the spectacle to do much about it at the moment. Here is the thought process that I believe is taking place.
HTTP is a protocol. A protocol is essentially a set of statements that can be sent to and fro in some well-defined order to achieve some result. In order to be easily understood by the parties involved in the protocol exchange, each statement is expressed in plain text and in a highly structured form. Statements have a small number of top-level types -- GET, POST, PUT and so on. Statements all share the same basic form -- a header that consists of name, value pairs and an optional body....
Now, re-read the previous paragraph having mentally substituted the word "statement" with the word "document".
Did that get your XML hammer twitching? Lets keep going. An XML document corresponding to the HTTP protocol concept of a GET request for the home page of propylon.com might look like this:
<http type="get" version="1.1" url="propylon.com">
<header>
<Accept>text/html</Accept>
</header>
</http>
So, what is wrong with this picture? Well, in terms of theory I suspect all is well. I don't see any insurmountable problems in re-casting HTTP as say, XML-HTTP. In theory, it would actually make life easier I guess. It would allow Web proxies and other sorts of intermediaries to route and process content in clever ways beyond the simple header processing currently possible. It has the intellectually satisfying appeal of a unified syntax....
In practical terms of course, large amounts of Web infrastructure software expect HTTP headers to appear the way TBL designed them in the first place. Today's proxies and routers would take a dim view of an XMLised HTTP.
However, we may be able to get chocolate on both sides of this particular biscuit. How about this?
POST propylon.com 1.1
http-accept: text/html
<http type = "get" version="1.0" url="propylon.com">
<header>
<Accept>text/html</Accept>
</header>
</http>
This approach purposely mirrors some of the key syntax from the legacy (!!!) HTTP protocol but keeps the normative version of the protocol statement/document in the payload/XML. Interesting.
This reminds me of something...what is it I wonder? Ah! I remember SOAP! Everything is an, um, POST request. Everything is in the XML encoded payload. SOAP headers are the moral equivalent of HTTP's headers.
But why stop there? We could apply the same logic (if "logic" is not too strong a word) to other statement-oriented protocols like FTP, SMTP, POP3, IMAP4, and NNTP?
Come to think of it, where does that leave some of the newer protocols that have sprung up in recent times? What about Jabber, which uses an XML statement language? What about WebDav, which uses an XML-based statement language?
Frankly, I don't know, but there does seem to be, shall we say, room for consolidation. I also detect room for some interesting commercial maneuvering -- especially around SOAP as a mega-hammer with which to strike a blow.
Like I say, I'm just the rabbit in the headlights of the oncoming juggernaut. Gee! Look at those pretty bright lights....
Sean is co-founder and Chief Technology Officer of Propylon and is an industry–recognised XML expert.