Introduction to HTTP Versions

Here's a brief history of HTTP:

---

HTTP 0.9

Simple application-level protocol for the Web, which did raw data transfer.

Defined in RFC 1945. Added MIME-like messages, header lines containing information about the data being transfered and modifiers for the request/response messages. As of May 1996, the current protocol version was HTTP 1.0 (draft 7).

Goal:

Achieve higher end-user performance than HTTP 1.0

Features include the following:

• Hierarchical proxy servers
• Caching
• Persistent connections
• Pipelining
• Address issue of applications that call themselves "HTTP/1.0" compliant, but don't really implement full protocol.


As of June 1999, HTTP/1.1 has been proposed as a draft standard in RFC2616 to the Internet Engineering Task Force's HTTP working group.

HTTP Digest Authentication Mechanism

Goal:

Addresses security

Summary:

Defines method for authenticating a user to an HTTP server without exposing user's passwords to potential eavsedroppers.  Method uses cryptographic hashes, or message digests.  This is an improvement over HTTP's original "Basic" authentication, which is in common use today.

As of June 1999, latest proposal is RFC 2617.

Another proposed modification of HTTP 1.0 is HTTP-NG (NG=Next Generation).

Problems Addressed:

• HTTP 1.x is complex and becoming strained.
• HTTP 1.x is not modular.  It mixes three concerns:
  • message transport
  • remove method invocation
  • methods historically for document processing (form processing and searching)
• People are trying to layer complex applications on HTTP 1.x
• People are "tunneling" various application protocols through HTTP 1.x's GET and POST methods - making it hard for a firewall to identify what the purpose of an HTTP message.

Key features include:

• Simplicity
• Distributed extensibility (see later)
• Global scalability (Web performance ok as Internet size increases)
• Greater efficiency than HTTP 1.x
• Layering:

For more info:

• HTTP-NG Activity Statement
• HTTP-NG Overview: Problem Statement, Requirements, and Solution Outline, IETF Internet Draft, November 17, 1998

(Formerly known as the Protocol Extension Protocol)

Motivation:

Why use extensions? Changing HTTP is a big deal: software on every Web server and browser must be replaced.

With extensions, you could install a protocol extension on your server -- like one to conduct electronic payment:
 

If I install the extension in my browser, I could use your service. So individual browser and server operators in the Web could upgrade as they see fit.

Draft proposal document:

A proposal for allowing private parties to agree on extensions to HTTP is described in a draft proposal as of March 1999.  This allows private parties to add new features to HTTP without modifying the HTTP spec itself.

Example scenarios of protocol extensions:

• Require server to add a digital signature to each HTTP file returned
• Use a real time protocol within HTTP
• Distributed authoring
• Collaboration
• Printing
• Remote procedure call mechanisms

How it works:

• Associate each extension with a globally unique identifier.
• Use HTTP header fields to carry extension identifier and related information between parties involved in extended communication.