On the use of HTTP as a Substrate
RFC 3205

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                           K. Moore
Request for Comments: 3205                       University of Tennessee
BCP: 56                                                    February 2002
Category: Best Current Practice

                   On the use of HTTP as a Substrate

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   Recently there has been widespread interest in using Hypertext
   Transfer Protocol (HTTP) as a substrate for other applications-level
   protocols.  This document recommends technical particulars of such
   use, including use of default ports, URL schemes, and HTTP security
   mechanisms.

1. Introduction

   Recently there has been widespread interest in using Hypertext
   Transfer Protocol (HTTP) [1] as a substrate for other applications-
   level protocols.  Various reasons cited for this interest have
   included:

   o  familiarity and mindshare,

   o  compatibility with widely deployed browsers,

   o  ability to reuse existing servers and client libraries,

   o  ease of prototyping servers using CGI scripts and similar
      extension mechanisms,

   o  ability to use existing security mechanisms such as HTTP digest
      authentication [2] and SSL or TLS [3],

   o  the ability of HTTP to traverse firewalls, and

   o  cases where a server often needs to support HTTP anyway.

Moore                    Best Current Practice                  [Page 1]
RFC 3205                     HTTP Layering                 February 2002

   The Internet community has a long tradition of protocol reuse, dating
   back to the use of Telnet [4] as a substrate for FTP [5] and SMTP
   [6].  However, the recent interest in layering new protocols over
   HTTP has raised a number of questions when such use is appropriate,
   and the proper way to use HTTP in contexts where it is appropriate.
   Specifically, for a given application that is layered on top of HTTP:

   o  Should the application use a different port than the HTTP default
      of 80?

   o  Should the application use traditional HTTP methods (GET, POST,
      etc.) or should it define new methods?

   o  Should the application use http: URLs or define its own prefix?

   o  Should the application define its own MIME-types, or use something
      that already exists (like registering a new type of MIME-directory
      structure)?

   This memo recommends certain design decisions in answer to these
   questions.

   This memo is intended as advice and recommendation for protocol
   designers, working groups, implementors, and IESG, rather than as a
   strict set of rules which must be adhered to in all cases.
   Accordingly, the capitalized key words defined in RFC 2119, which are
   intended to indicate conformance to a specification, are not used in
   this memo.

2. Issues Regarding the Design Choice to use HTTP

   Despite the advantages listed above, it's worth asking the question
   as to whether HTTP should be used at all, or whether the entire HTTP
   protocol should be used.

2.1 Complexity

   HTTP started out as a simple protocol, but quickly became much more
   complex due to the addition of several features unanticipated by its
   original design.  These features include persistent connections, byte
   ranges, content negotiation, and cache support.  All of these are
   useful for traditional web applications but may not be useful for the
   layered application.  The need to support (or circumvent) these
   features can add additional complexity to the design and
   implementation of a protocol layered on top of HTTP.  Even when HTTP
   can be "profiled" to minimize implementation overhead, the effort of
   specifying such a profile might be more than the effort of specifying
   a purpose-built protocol which is better suited to the task at hand.

Moore                    Best Current Practice                  [Page 2]
RFC 3205                     HTTP Layering                 February 2002

   Even if existing HTTP client and server code can often be re-used,
   the additional complexity of layering something over HTTP vs. using a
   purpose-built protocol can increase the number of interoperability
   problems.

2.2 Overhead

   Further, although HTTP can be used as the transport for a "remote
   procedure call" paradigm, HTTP's protocol overhead, along with the
   connection setup overhead of TCP, can make HTTP a poor choice.  A
   protocol based on UDP, or with both UDP and TCP variants, should be
   considered if the payloads are very likely to be small (less than a
   few hundred bytes) for the foreseeable future.  This is especially
   true if the protocol might be heavily used, or if it might be used
   over slow or expensive links.