On the use of HTTP as a Substrate
RFC 3205
Document | Type |
RFC - Best Current Practice
(February 2002; No errata)
Also known as BCP 56
Was draft-moore-using-http (individual)
|
|
---|---|---|---|
Author | Keith Moore | ||
Last updated | 2020-07-29 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3205 (Best Current Practice) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text