mirror of https://github.com/lianthony/NT4.0
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
856 lines
28 KiB
856 lines
28 KiB
David M. Kristol
|
|
|
|
INTERNET DRAFT AT&T Bell Laboratories
|
|
|
|
<draft-kristol-http-extensions-00.txt>
|
|
|
|
January 1995 Expires July 1995
|
|
|
|
|
|
|
|
|
|
|
|
A Proposed Extension Mechanism for HTTP
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Status of this Memo
|
|
|
|
|
|
|
|
This document is an Internet-Draft. Internet-Drafts are
|
|
|
|
working documents of the Internet Engineering Task Force
|
|
|
|
(IETF), its areas, and its working groups. Note that other
|
|
|
|
groups may also distribute working documents as Internet-
|
|
|
|
Drafts.
|
|
|
|
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six
|
|
|
|
months and may be updated, replaced, or obsoleted by other
|
|
|
|
documents at any time. It is inappropriate to use Internet-
|
|
|
|
Drafts as reference material or to cite them other than as
|
|
|
|
``work in progress.''
|
|
|
|
|
|
|
|
To learn the current status of any Internet-Draft, please
|
|
|
|
check the ``1id-abstracts.txt'' listing contained in the
|
|
|
|
Internet- Drafts Shadow Directories on ftp.is.co.za (Africa),
|
|
|
|
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
|
|
|
|
ds.internic.net (US East Coast), or ftp.isi.edu (US West
|
|
|
|
Coast).
|
|
|
|
|
|
|
|
This is author's draft 2.9. The previously available author's
|
|
|
|
draft was 1.3.
|
|
|
|
|
|
|
|
|
|
|
|
1. ABSTRACT
|
|
|
|
|
|
|
|
HTTP, the hypertext transfer protocol, underpins the World-Wide Web
|
|
|
|
(WWW). As the Web has grown, pressures have mounted to add a variety of
|
|
|
|
facilities to HTTP. Some of the new features that have been proposed
|
|
|
|
include: keep-alive, packetized data, compression, security, and
|
|
|
|
payment. This memo offers an alternative: well-defined hooks in a
|
|
|
|
slightly modified HTTP framework that make it possible to add extensions
|
|
|
|
to the basic protocol in a way that will retain compatible behavior
|
|
|
|
between clients and servers, yet allow both clients and servers to
|
|
|
|
discover and use extended capabilities. The goal is to use HTTP as just
|
|
|
|
a transport mechanism, leaving other, higher-level (session) activities
|
|
|
|
to extensions.
|
|
|
|
|
|
|
|
|
|
|
|
2. MOTIVATION
|
|
|
|
|
|
|
|
One virtue of HTTP is that it is easy to modify: just add more request
|
|
|
|
or response headers. Unrecognized headers will be ignored by agents
|
|
|
|
(client or server) that don't understand them. Why is this approach
|
|
|
|
unacceptable? The following paragraphs will attempt to justify a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 1]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
different approach.
|
|
|
|
|
|
|
|
2.1 Generality
|
|
|
|
|
|
|
|
A common, well-defined framework by which to introduce extensions
|
|
|
|
reduces the danger of uncontrolled proliferation of incompatible
|
|
|
|
extensions. Vendors that want to add extensions can do so in a
|
|
|
|
predictable way. Client and server software will be better able to
|
|
|
|
predict what kinds of headers they will encounter.
|
|
|
|
|
|
|
|
2.2 Simplicity and Modularity
|
|
|
|
|
|
|
|
The server and client architectures should be kept simple. If
|
|
|
|
extensions can be recognized easily, it becomes possible to posit the
|
|
|
|
following architecture. A client (server) comprises a core part.
|
|
|
|
Extensions are handed off to an extensions manager, which dispatches
|
|
|
|
extension requests to the appropriate handler, such as a security
|
|
|
|
manager, payment manager, etc. If the interface between the core part
|
|
|
|
and the extensions manager, and between the extensions manager and the
|
|
|
|
individual extension managers, is well-defined, the core part of a
|
|
|
|
client (server) can be quite ignorant of what is actually being done by
|
|
|
|
the various extensions. Thus this architecture leads to a highly
|
|
|
|
modular design into which it is possible to ``plug'' new extensions,
|
|
|
|
while the core part remains simple. Vendors of extensions could supply
|
|
|
|
matched plug-in parts for them to client and server implementors, to
|
|
|
|
incorporate them in their products.
|
|
|
|
|
|
|
|
2.3 Recognizable Extensions
|
|
|
|
|
|
|
|
The scheme proposed here makes it easy to identify requests for
|
|
|
|
extensions quickly. Requests for, or acceptance of, extensions is
|
|
|
|
signaled by Extension: request/response headers. Because they are
|
|
|
|
easily identified, a caching server can recognize headers for extensions
|
|
|
|
and store them as part of the cached information.
|
|
|
|
|
|
|
|
(Caching requires further consideration. It may be necessary for
|
|
|
|
caching servers not to cache information that was obtained using
|
|
|
|
extensions, since those extensions often entail security or payment.)
|
|
|
|
|
|
|
|
Using the HTTP version number to determine what extensions are present
|
|
|
|
is a bad idea. Extensions are often disjoint, and clients and servers
|
|
|
|
should be able to ``mix and match'' the ones they can support. The HTTP
|
|
|
|
version number is too crude a discriminant and should be reserved for
|
|
|
|
true changes to the base protocol. The extension mechanism proposed
|
|
|
|
here merely uses HTTP for transport.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 2]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.4 Who's in Charge?
|
|
|
|
|
|
|
|
HTTP headers are likely to require approval from IANA. Thus, using
|
|
|
|
multiple headers for different extensions may impede new applications of
|
|
|
|
the World-Wide Web. It is easier to get two headers approved that
|
|
|
|
enable a whole range of extensions, and it carves out a hunk of name
|
|
|
|
space that can be controlled separately, possibly by W3C (World-Wide Web
|
|
|
|
Consortium).
|
|
|
|
|
|
|
|
2.5 Wrapping Better Than MIME
|
|
|
|
|
|
|
|
Wrapping, described below, has capabilities that MIME cannot supply.
|
|
|
|
Specifically, security may require that the actual request be obscured.
|
|
|
|
The WRAPPED method in this proposal makes it possible to encrypt the
|
|
|
|
actual request. A snooper would see only the WRAPPED request method and
|
|
|
|
the extension header (with, presumably, enough information to describe
|
|
|
|
how to decrypt the actual request).
|
|
|
|
|
|
|
|
|
|
|
|
3. CONCEPTS
|
|
|
|
|
|
|
|
The proposed extension mechanism has two fundamental concepts: wrapping
|
|
|
|
and negotiation.
|
|
|
|
|
|
|
|
3.1 Wrapping
|
|
|
|
|
|
|
|
Wrapping implies that a core set of information has information added
|
|
|
|
before and after it. In some cases the information added may comprise
|
|
|
|
just headers. The core information may itself be changed as well, such
|
|
|
|
as when it is encrypted. The information added as the pre-wrapper must
|
|
|
|
convey enough information to the recipient so it can unwrap the
|
|
|
|
information. Either a client or server can do the wrapping, although I
|
|
|
|
assume that the server more often does the wrapping.
|
|
|
|
|
|
|
|
3.2 Negotiation
|
|
|
|
|
|
|
|
Before a sender wraps information, it must be sure the receiver can
|
|
|
|
unwrap it. Thus the two parties must negotiate what kind of wrapping is
|
|
|
|
desirable. Therefore a (prospective) receiver (initiator) tells a
|
|
|
|
sender (responder) what forms of wrapping it accepts, and whether they
|
|
|
|
are acceptable always, or sometimes. The sender responds with a
|
|
|
|
suitably wrapped response. ``One-of'' wrappings must always be used,
|
|
|
|
but the sender can choose at will from a group of such wrappings.
|
|
|
|
``Sometimes'' wrappings may be used at the discretion of the responder.
|
|
|
|
|
|
|
|
3.3 Recursion
|
|
|
|
|
|
|
|
Wrappings can be recursive. To give but one example, a core message
|
|
|
|
might be wrapped thus: packetize(security(payment(core))). The
|
|
|
|
notation implies that, given a core message, first a payment wrapping is
|
|
|
|
applied, followed by a security wrapper, followed by packetization. The
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 3]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
receiver must unwrap the message from outside in, i.e., packetization
|
|
|
|
first.
|
|
|
|
|
|
|
|
|
|
|
|
4. NOTATIONAL CONVENTIONS
|
|
|
|
|
|
|
|
This proposal uses the notational conventions of the (draft)
|
|
|
|
specification, Hypertext Transfer Protocol - HTTP/1.0, Berners-Lee,
|
|
|
|
Fielding, Frystyk Nielsen.
|
|
|
|
|
|
|
|
|
|
|
|
5. EXTENSIONS TO HTTP 1.0
|
|
|
|
|
|
|
|
The proposed extension mechanism requires small changes in the existing
|
|
|
|
HTTP, to add two methods and two request headers.
|
|
|
|
|
|
|
|
5.1 Methods
|
|
|
|
|
|
|
|
5.1.1 GETEXT get extensions
|
|
|
|
The HEAD method in HTTP only provides a limited amount of information
|
|
|
|
about how the server would respond to a GET request. GETEXT provides
|
|
|
|
information about how the server would respond (at least for extensions)
|
|
|
|
for any method.
|
|
|
|
|
|
|
|
<getext> ::= "GETEXT" <url> "HTTP/1.0"
|
|
|
|
<url> ::= *
|
|
|
|
/ <path part of URL>
|
|
|
|
|
|
|
|
A client sends a request with the GETEXT method to a server to learn
|
|
|
|
what extensions the server supports.
|
|
|
|
|
|
|
|
The GETEXT method may have an optional Extension: request header with
|
|
|
|
the following form:
|
|
|
|
|
|
|
|
<getext-hdr> ::= "Extension:" "HTTP/Method" "method=" <method>
|
|
|
|
<method> ::= "GET" / "PUT" / "POST" / ...
|
|
|
|
|
|
|
|
Semantics
|
|
|
|
|
|
|
|
The server reports the extensions as response headers, identical to the
|
|
|
|
request headers that are described in the next section, that apply.
|
|
|
|
There are four cases, depending on whether an explicit <url> is present
|
|
|
|
and whether an Extension: header is present. In each case the result is
|
|
|
|
the intersection set of extensions for the method(s) and URL(s)
|
|
|
|
specified by the GETEXT request.
|
|
|
|
|
|
|
|
<url> ::= *, no Extension: request header
|
|
|
|
The server returns the set of Extension: response headers that
|
|
|
|
apply to any URL and any method on the server.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 4]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<url> ::= *, Extension: request header present
|
|
|
|
The server returns the set of Extension: response headers that
|
|
|
|
would apply if the server got a request comprising the
|
|
|
|
<method> in the Extension: request header and any URL.
|
|
|
|
|
|
|
|
<url> ::= URL, no Extension: request header
|
|
|
|
The server returns the set of Extension: response headers that
|
|
|
|
would apply if the server got a request comprising any
|
|
|
|
acceptable method applied to the selected URL.
|
|
|
|
|
|
|
|
<url> ::= URL, Extension: request header present
|
|
|
|
The server returns the set of Extension: response headers that
|
|
|
|
would apply if the server got a request comprising the
|
|
|
|
<method> in the Extension: request header and the specified
|
|
|
|
URL.
|
|
|
|
|
|
|
|
5.2.1 WRAPPED wrapped request
|
|
|
|
|
|
|
|
<wrapped> ::= "WRAPPED" "*" "HTTP/1.0"
|
|
|
|
|
|
|
|
A client sends a request with this method to tell a server that the
|
|
|
|
request is wrapped. The request headers (next section) specify exactly
|
|
|
|
how the request is wrapped. The server must peel the wrappings one
|
|
|
|
layer at a time until it encounters a normal request, which it can then
|
|
|
|
process. The value of what would normally be the URL field, shown above
|
|
|
|
as *, is ignored.
|
|
|
|
|
|
|
|
5.3 Request Headers
|
|
|
|
|
|
|
|
Two new request headers specify extensions. Their syntax and semantics
|
|
|
|
are given below.
|
|
|
|
|
|
|
|
5.3.1 Extension: Header
|
|
|
|
|
|
|
|
<extension> ::= "Extension:" <cat-class> [<av-pairs>]
|
|
|
|
<cat-class> ::= <category> "/" <class>
|
|
|
|
<category> ::= <alpha-numeric string>
|
|
|
|
; kind of generic extension
|
|
|
|
<class> ::= <alpha-numeric string>
|
|
|
|
; class within generic extension
|
|
|
|
<av-pairs> ::= <av-pair> [";" <av-pair>]
|
|
|
|
<av-pair> ::= <attr> "=" <value>
|
|
|
|
<attr> ::= <alpha-numeric string>
|
|
|
|
<value> ::= <alpha-numeric string>
|
|
|
|
|
|
|
|
The Extension: request header may wrap, RFC822-style, onto multiple
|
|
|
|
lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 5]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Semantics
|
|
|
|
|
|
|
|
<category> describes the generic extension, for example security,
|
|
|
|
payment. (Should the list of extensions be controlled by W3C?) A
|
|
|
|
responder that receives an unrecognized <category> responds with an
|
|
|
|
error if the <av-pair> required=oneof is present and ignores the header
|
|
|
|
otherwise.
|
|
|
|
|
|
|
|
<class> specifies a member of the <category>. For example, <category>
|
|
|
|
payment might have <class>s Visa, MasterCard, Ecash, etc. If a
|
|
|
|
<category> has no <class>s, * must be used as the <class>.
|
|
|
|
|
|
|
|
Attribute-value pairs (<av-pairs>) are optional. The only attribute
|
|
|
|
that is defined for all <category>s is required, with possible values
|
|
|
|
oneof and sometimes. If the required attribute is present for an
|
|
|
|
Extension: header, it must be part of the first <av-pair>.
|
|
|
|
|
|
|
|
The algorithm for choosing among Extension: headers is described in
|
|
|
|
NEGOTIATION, below.
|
|
|
|
|
|
|
|
5.4.1 Extension-Order: Header
|
|
|
|
|
|
|
|
<extension-order> ::= "Extension-Order:" 1#<cat-class>
|
|
|
|
|
|
|
|
The Extension-Order: header provides a way for a client or server to
|
|
|
|
specify the order in which extensions must be applied. (MIME headers
|
|
|
|
are unordered by definition.)
|
|
|
|
|
|
|
|
5.5 Wrapped Response
|
|
|
|
|
|
|
|
A wrapped response comprises a status code of 207 (Wrapped), a single
|
|
|
|
Extension: response header that describes the outermost wrapping, and a
|
|
|
|
blank line. The body of the response comprises the wrapped response.
|
|
|
|
The wrapping must be defined in such a way that the body can be
|
|
|
|
unwrapped to produce a new response, complete with status line, response
|
|
|
|
header line(s), blank line, and new body. The specifics of that
|
|
|
|
wrapping are outside the scope of this document and are specific to a
|
|
|
|
given extension. The resulting inner response may also be a wrapped
|
|
|
|
response, in which case the unwrapping occurs recursively.
|
|
|
|
|
|
|
|
A response code of 409 by a server denotes a Wrapping Required response.
|
|
|
|
The response headers specify both the type and order of wrapping that
|
|
|
|
the server requires from the client. (Note that in this case the server
|
|
|
|
acts as an initiator and should provide required= <av-pair>s for the
|
|
|
|
Extension: response headers it returns.)
|
|
|
|
|
|
|
|
5.5.1 Response Headers An Extension: response header is identical in
|
|
|
|
form and content to a corresponding request header. A responder's
|
|
|
|
header does not contain a required= <av-pair>, because the presence of
|
|
|
|
the Extension: header means the extension request has been honored,
|
|
|
|
whether it was optional or mandatory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kristol [Page 6]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6. NEGOTIATION
|
|
|
|
|
|
|
|
This section describes in more detail the negotiation process. It
|
|
|
|
describes the roles of initiators and responders and how they should use
|
|
|
|
and respond to Extension: and Extension-Order: headers. Either clients
|
|
|
|
or servers may be initiators or responders.
|
|
|
|
|
|
|
|
[This first attempt will undoubtedly be mushy.]
|
|
|
|
|
|
|
|
6.1 Initiators
|
|
|
|
|
|
|
|
An initiator informs a responder of extension capabilities that are
|
|
|
|
either mandatory or optional to use. Each capability is described by an
|
|
|
|
Extension: (request or response) header. Mandatory extensions must have
|
|
|
|
required=oneof as the first <av-pair> of the header. If no required=
|
|
|
|
<av-pair> is present in an initiator's header, the default is
|
|
|
|
required=sometimes.
|
|
|
|
|
|
|
|
An initiator can advertise to a responder many <class>s for a particular
|
|
|
|
<category>, and many extension <category>s. Based on the negotiation
|
|
|
|
selection algorithm (below), a responder may (and sometimes must) choose
|
|
|
|
among them. How the initiator chooses which extensions to advertise is
|
|
|
|
outside the scope of this proposal.
|
|
|
|
|
|
|
|
6.2 Responders
|
|
|
|
|
|
|
|
A responder informs an initiator of which extensions it has selected.
|
|
If the initiator has specified multiple <class>s for a particular
<category>, the responder must choose to honor either one or none of the
choices. When the initiator has specified mandatory extensions
(required=oneof) for a <category>, the responder must choose one. For
optional extensions (required=sometimes), the responder informs the
initiator of which ones, if any, it has chosen to use.
What happens when a responder cannot honor a mandatory extension depends
on whether it is a client or server. A client responder would typically
inform a user that it cannot complete a request because it lacks some
capability that the server requires (such as authentication or a
suitable payment method). A server responder would return an error
response code to the client, preferably with an informative HTML message
for the client to display to describe the failure.
6.3 Negotiation Selection Algorithm
A responder uses the negotiation selection algorithm to choose among
possible <class>s in a given <category>, and to define the order in
which extensions in different <category>s are applied.
For expository purposes, assume each <cat-class> part of an Extension-
Order: header is assigned an integer index from 1 (first) to N (last),
based on its lexical order in the header. If there is no Extension-
Kristol [Page 7]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
Order: header, the indexes are assigned arbitrarily by the responder.
Note that if there is only one Extension: header, the Extension-Order:
header is redundant.
6.3.1 Selection All the extensions in the same <category> (call them
category-options) are treated as a group. If any category-option in the
group has the <av-pair> required=oneof (a mandatory category), then any
category-option in the group that does not have required=oneof is
discarded. The responder then considers each remaining category-option
in turn, choosing the one it prefers from the group. Note that at this
point all the members of the group must have the same required= value,
either oneof or sometimes. (How the responder chooses the one ``it
prefers'' is an implementation issue, outside the scope of this
proposal.)
If the responder cannot support any of the category-options for a
mandatory category, it responds with an error, as indicated earlier.
For an optional category, if the responder cannot support, or chooses
not to honor, an extension, the responder simply does not apply the
extension.
6.3.2 Order After the responder has identified the extensions it will
honor, based on the initiator's Extension: headers, it applies them in
the order of the index numbers of the honored <cat-class>s.
6.3.3 Exceptional Conditions
1. If an Extension-Order: header is present, any Extension: header to
be considered in the selection process must have its <cat-class>
listed by the Extension-Order: header.
2. If more than one Exception: header has the same <cat-class>, the
responder should reject the request.
3. If a <cat-class> appears in an Exception-Order: header, and there
is no Exception: header with the same <cat-class>, the responder
should behave as though the <cat-class> were omitted from the
Exception-Order: header.
7. EXAMPLE 1: SIMPLE AUTHENTICATION
The Basic authentication scheme can be recast in the framework of the
HTTP extension mechanism. Assume the requested (local) URL on the
server is /foo/bar.
Kristol [Page 8]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
7.1 Client -> Server
GET /foo/bar HTTP/1.0
Accept: text/html, ...
[blank line]
7.2 Server -> Client [Server is initiator]
HTTP/1.0 409 Wrapping Required
Date: Wed, 28 Dec 1994 10:59:13 GMT
Server: HTD/0.9
MIME-version: 1.0
Extension: Security/Basic required=oneof;Realm="Demonstration"
7.3 Client -> Server [Client is responder]
WRAPPED * HTTP/1.0
Extension: Security/Basic data=ZG1rOnBhc3N3b3Jk
[blank line]
====
GET /foo/bar HTTP/1.0
Accept: text/html, ...
====
(Note: pretend ==== is used to ``wrap'' the inner request.)
7.4 Server -> Client
HTTP/1.0 200 OK
Date: Wed, 28 Dec 1994 10:59:15 GMT
Server: HTD/0.9
MIME-version: 1.0
Content-type: text/html
Last-modified: Thu, 17 Nov 1994 19:35:21 GMT
Content-length: 3729
[body]
8. EXAMPLE 2: PAYMENT AND ENCRYPTION
This more extended example demonstrates how the extension mechanism can
be used to support both security and payment. In the example, the
payment manager relies on an existing security manager to provide the
encryption that secures a credit card number.
Kristol [Page 9]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
8.1 Client -> Server
GET /foo/bar HTTP/1.0
Accept: text/html, ...
[blank line]
8.2 Server -> Client [Server is initiator]
The server requires both payment and security (encryption). The payment
information must be supplied first, followed by the encryption. Note
that there is no need for an actual ``wrapping'' by the payment piece.
HTTP/1.0 409 Wrapping Required
Date: Wed, 28 Dec 1994 10:59:13 GMT
Server: HTD/0.9
MIME-version: 1.0
Extension: Security/SimpleDES required=oneof;
keyname=OpenSesame; nonce=873955
Extension: Security/SHTTP required=oneof;
(S-HTTP parameters)
Extension: Payment/MasterCharge required=oneof;
cost=2; units=USD; mult=0
Extension: Payment/GreenCard required=oneof;
cost=2; units=USD; mult=0
Extension: Payment/American_Excess required=oneof;
cost=25; units=USD; mult=-1
Extension-Order: Security/SHTTP,
Security/SimpleDES,
Payment/MasterCharge,
Payment/American_Excess,
Payment/GreenCard
[blank line]
8.3 Client -> Server [Client is responder]
Client provides server with payment information. It chooses (presumably
with the user's help) which of the three payment methods, MasterCharge,
GreenCard, American_Excess, to use. It also chooses between the two
security methods. Note that the ``wrapping'' for the payment part just
comprises adding a header. The security piece does wrap the request,
however.
Kristol [Page 10]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
WRAPPED * HTTP/1.0
Extension: Security/SimpleDES keyname=OpenSesame; nonce=873955
[blank line]
====
GET /foo/bar HTTP/1.0
Accept: text/html, ...
Extension: Payment/GreenCard cost=2; units=USD; mult=0;
cardno=11112223333444
====
Pretend ==== is used to ``wrap'' the inner request, and that the inner
request is encrypted using simple DES with a key named OpenSesame, a
shared secret between the client and server. The wrapping could just as
well use MIME multipart syntax, but that's a decision to be made by the
particular extension manager.
8.4 Server -> Client
Server accepts payment and returns a receipt to the client. The server
could, optionally, wrap the response to protect the receipt.
HTTP/1.0 200 OK
Date: Wed, 28 Dec 1994 11:01:56 GMT
Server: HTD/0.9
MIME-version: 1.0
Content-type: text/html
Last-modified: Thu, 17 Nov 1994 19:35:21 GMT
Content-length: 3729
Extension: Payment/GreenCard cost=2; units=USD; mult=0;
Receipt="You paid $2. Thank you for using AT&T."
[body]
9. EXAMPLE 3: GETEXT
This example shows how the GETEXT method might be used.
9.1 Client -> Server
GETEXT /foo/bar HTTP/1.0
Extension: HTTP/Method method=GET
[blank line]
9.2 Server -> Client
Kristol [Page 11]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
HTTP/1.0 200 OK
Date: Wed, 28 Dec 1994 10:59:13 GMT
Server: HTD/0.9
MIME-version: 1.0
Extension: Security/SimpleDES required=oneof;
keyname=OpenSesame; nonce=873955
Extension: Security/SHTTP required=oneof;
(S-HTTP parameters)
Extension: Payment/MasterCharge required=oneof;
cost=2; units=USD; mult=0
Extension: Payment/GreenCard required=oneof;
cost=2; units=USD; mult=0
Extension: Payment/American_Excess required=oneof;
cost=25; units=USD; mult=-1
Extension-Order: Security/SHTTP,
Security/SimpleDES,
Payment/MasterCharge,
Payment/American_Excess,
Payment/GreenCard
[blank line]
10. <category> HTTP Extensions
The proposed mechanism can be used for extensions to HTTP itself, as
well as to what might be considered ``outboard'' matters, like security
and payment. Such extensions would comprise the <category> HTTP. Two
extensions to HTTP/1.0 have been frequently discussed. Both can be
accommodated by this proposed mechanism.
10.1 Packetization HTTP/Packetize
Packetization divides a message into hunks of not more than a fixed
size. It is well-suited for transmitting the output of a script for
which the total size of the message is unknown when the script begins to
run.
<packet-hdr> ::= "Extension:" "HTTP/Packetize"
"required=sometimes" [<size>]
<size> ::= ";" "size=" <positive, non-zero decimal number>
The initiator (usually a client) announces its willingness to accept
responses in packetized form, with packets no larger than <size>, but
packetization is optional. The initiator must supply <size>.
The responder (usually a server) announces that it plans to use
packetization in its response by returning a similar Extension: header,
omitting the <size> and required=.
I have omitted details of what a packetized response looks like. A
typical implementation produces packets that comprise a decimal byte
Kristol [Page 12]
INTERNET DRAFT Proposed HTTP Extension Mechanism January 1995
count, followed by that many bytes (line terminators included). A zero
or negative count signifies end of data.
10.2 Keep-connection HTTP/KeepConnection
One of the performance defects of HTTP is that clients often open many
connections to the same server to get images for a document they just
fetched. Connections are expensive in time and resources. It would be
better to pass follow-up requests over an already-open connection.
<keep-conn> ::= "Extension:" "HTTP/KeepConnection"
"required=sometimes" [<timeout>]
<timeout> ::= ";" "timeout=" <timeout in seconds>
A client (initiator) would signal its ability and willingness to hold a
connection open by passing this request header. The <timeout> advises
the server how long it would like the connection held open.
A server (responder) would indicate it had honored the request by
returning the same header, minus the required= part. The server can
respond with a different <timeout> to say how long it plans to hold open
the connection, but that information is strictly advisory.
Note that, as a practical matter, HTTP/KeepConnection must be used with
HTTP/Packetize, because in some instances (e.g., output from scripts),
the server doesn't know how long its output to the client will be, and
it currently signals the end of data by closing the connection.
Packetization lets a server pass back data to a client in manageable
chunks, rather than buffer the entire response and send a correct
Content-length header.
11. ACKNOWLEDGEMENTS
Jeff Hostetler, Spyglass, Inc., originally suggested the idea of
``wrapping'' to me.
12. AUTHOR'S ADDRESS
David M. Kristol
AT&T Bell Laboratories
600 Mountain Ave. Room 2A-227
Murray Hill, NJ 07974
Phone: (908) 582-2250
FAX: (908) 582-5809
Email: [email protected]
Kristol [Page 13]
|