Re: HTTP Extensions Framework status?

To expand a bit on what Keith has mentioned, HTTP is not designed to be
a transport protocol.  It is a transfer protocol in which the messages
reflect the semantics of the Web architecture by performing actions on
resources through the transfer and manipulation of representations of
those resources.  It is possible to achieve a wide range of functionality
using this very simple interface, but following the interface is required
in order for HTTP semantics to remain visible to intermediaries.

That is why HTTP goes through firewalls.  Most of the extensions that
have been proposed lately (aside from DAV and its ilk) have merely used
HTTP as a way to move other application protocols through a firewall,
which is a fundamentally stupid idea.  Not only does it defeat the purpose
of having a firewall, but it won't work for the long term because firewall
vendors will simply have to perform protocol filtering to continue their
existance.  It therefore makes no sense to do those extensions on top of
HTTP, since the only thing HTTP accomplishes in that situation is to add
overhead from a legacy syntax.

However, this is not an argument against the HTTP extensions framework.
Given the unavoidable (at this point) presence of protocol filtering,
the best way to accomplish real extensions within HTTP is through an
extension framework that identifies each extension in such a way that an
intermediary can strip it if it isn't wanted.  The only real question
then is whether there is any desire for such mandatory extensions within
HTTP/1.x applications, which I think is the main reason the framework
deserves the Experimental tag.

As an implementer, my primary objection to the HTTP/1.x extensions framework
has always been that it excessively complicates the interface to the
point where it would be far more efficient for us to just redesign HTTP
and issue HTTP/2.0 using a syntax that incorporates the design goals of
the extension framework.  However, again that does not argue against the
creation of an HTTP/1.x extensions framework, since the more experience
we have with these things IN PRACTICE, the better.  I can worry about the
new protocol at a later time.

As far as the Experimental tag hindering the progression of other protocols,
I can say from experience that none of the HTTP extensions proposed so far,
aside from the DAV ones, have deserved the status of anything better than
Experimental.  I am certain that the extensions framework will progress
onto the standards track before any of those half-baked ideas.

If people are in such a hurry to extend HTTP/1.x, what they should be
working on is a set of specifications that establish a registry for the
various protocol elements not defined by MIME.  That task is so boring
that nobody has volunteered to do it, even though it is necessary for
HTTP to be extended in a coherent manner.

....Roy

Received on Tuesday, 7 December 1999 21:14:53 UTC