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.
656 lines
22 KiB
656 lines
22 KiB
[ THIS DOCUMENT IS NOT YET COMPLETE]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HTTP Working Group Simon Spero
|
|
|
|
Internet Draft
|
|
|
|
<XXX filename>
|
|
|
|
|
|
|
|
Next Generation Hypertext Transport Protocol
|
|
|
|
|
|
|
|
March 26th 1995
|
|
|
|
Expires: < whenever >
|
|
|
|
|
|
|
|
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. Internet-Drafts may be updated, replaced, or obsoleted
|
|
|
|
by other documents at any time. It is not appropriate to use
|
|
|
|
Internet-Drafts as reference material or to cite them other
|
|
|
|
than as a "working draft" or "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 ds.internic.net (US East
|
|
|
|
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
|
|
|
|
or munnari.oz.au (Pacific Rim).
|
|
|
|
|
|
|
|
If consensus is reached on this document, it will be
|
|
|
|
forwarded to the IESG with the recommendation that it be
|
|
|
|
processed as a Proposed Standard for hypertext transport.
|
|
|
|
|
|
|
|
|
|
|
|
1 Introduction.
|
|
|
|
|
|
|
|
This document contains the specification for HTTP-NG. The
|
|
|
|
architecture for this protocol is described in
|
|
|
|
http://www.w3.org/hypertext/WWW/Protocols/HTTP-NG/http-ng-status.html.
|
|
|
|
please read that document before reading this one.
|
|
|
|
|
|
|
|
The document is divided into two parts. The first part explains some
|
|
|
|
of the concepts behind HTTP-NG, and gives an overview of the
|
|
|
|
operations defined in this version of the specification. The second
|
|
|
|
contains the syntax and detailed semantics for these operations.
|
|
|
|
|
|
|
|
All the syntax in this document is expressed in ASN.1; only a
|
|
|
|
simplified subset is used. A basic introduction to ASN.1 can be found
|
|
|
|
in [open-book].
|
|
|
|
|
|
|
|
2 Overview and Concepts.
|
|
|
|
|
|
|
|
HTTP-NG uses a variation of the standard request/response protocol
|
|
|
|
model. In its most basic form, HTTP-NG clients open connections to
|
|
|
|
servers, send requests, and receive responses. Unlike many other
|
|
|
|
protocols, HTTP-NG imposes few ordering constraints on this process.
|
|
|
|
Clients may send requests at any time; if the client indicates
|
|
|
|
permission, the server may respond to these requests in a different
|
|
|
|
order from which they were received, in an interleaved manner, or even
|
|
|
|
before the client has issued the corresponding request.
|
|
|
|
|
|
|
|
2.1.1 Transport Layer Issues.
|
|
|
|
|
|
|
|
HTTP-NG requires a reliable transport layer with low connection setup
|
|
|
|
costs. In an Internet environment, HTTP-NG operates using SCP over TCP.
|
|
|
|
The default port for HTTP-NG is XXX.
|
|
|
|
|
|
|
|
2.1.2 Protocol Operation.
|
|
|
|
|
|
|
|
2.1.2.1 Request/Response ordering
|
|
|
|
|
|
|
|
Messages are exchanged according to the negotiated level of
|
|
|
|
synchronicity.
|
|
|
|
|
|
|
|
If the level is synchronous, the server must complete the current
|
|
|
|
operation before starting the next operation. All operations must be
|
|
|
|
performed in the order in which they were received.
|
|
|
|
|
|
|
|
If the level is set to out-of-order, the server may respond to
|
|
|
|
messages in any order, but must complete each operation before
|
|
|
|
beginning the next.
|
|
|
|
|
|
|
|
If the level is set to interleaved, the server may respond to messages
|
|
|
|
in any order, and may also begin a response without waiting for
|
|
|
|
current responses to complete.
|
|
|
|
|
|
|
|
If the level is set to predictive, in addition to sending interleaved
|
|
|
|
responses, the server may also send responses before the corresponding
|
|
|
|
request has been received. This allows servers to send documents it
|
|
|
|
can predict the client will need without requiring extra round trips
|
|
|
|
for the client to specifically request this. This facility is needed
|
|
|
|
if the desired performance goals of 100 ms response times is to the
|
|
|
|
met over wide area networks.
|
|
|
|
|
|
|
|
2.1.2.2 Initializing The Connection.
|
|
|
|
|
|
|
|
Once the connection has been opened, it must be initialized. The
|
|
|
|
client sends an initialization request, indicating which methods it
|
|
|
|
supports, and what degree of synchronicity it desires. The server
|
|
|
|
responds with an initialization response, indicating the methods it
|
|
|
|
supports, and what level of synchronicity it will be used. The client
|
|
|
|
need not wait for the initialization response before sending further
|
|
|
|
requests. If a request is sent which is not supported by the server,
|
|
|
|
the server may indicate an error.
|
|
|
|
|
|
|
|
The initialization request and response must be the first messages
|
|
|
|
sent on each end of the connection.
|
|
|
|
|
|
|
|
If the client supports negotiation, it should send a negotiation
|
|
|
|
request immediately after the initialization request. This should
|
|
|
|
setup the basic parameters for the client, but need not contain the
|
|
|
|
full array of available options.
|
|
|
|
|
|
|
|
2.1.2.3 Normal Message Exchange.
|
|
|
|
|
|
|
|
Once initialization has been completed, the client and server are free
|
|
|
|
to begin exchanging requests and responses. The server must obey the
|
|
|
|
clients constraints on synchronicity at all times.
|
|
|
|
|
|
|
|
The server must not send any messages for which the client has not
|
|
|
|
indicated support.
|
|
|
|
|
|
|
|
The client may send a new initialization request at any time to change
|
|
|
|
the synchronicity or methods supported. If such a request is
|
|
|
|
received, the server must complete all requests sent before the
|
|
|
|
initialization request before sending the new initialization response
|
|
|
|
and using the new settings. The server may not process any new
|
|
|
|
incoming requests until the initialization response has been sent.
|
|
|
|
|
|
|
|
2.1.2.3a Error Responses.
|
|
|
|
|
|
|
|
If an error occurs, an error response will be returned. This response
|
|
|
|
contains a numeric identifier indicating the reason for failure,
|
|
|
|
together with operation specific information, and an optional string
|
|
|
|
containing a natural language explanation for the problem.
|
|
|
|
|
|
|
|
2.1.2.4 Request Cancellation.
|
|
|
|
|
|
|
|
A request may be canceled at any time. If a server receives a
|
|
|
|
cancellation request for an operation which has not been completed, it
|
|
|
|
should terminate that request. Because of latency issues, this
|
|
|
|
cancellation can not the guaranteed.
|
|
|
|
|
|
|
|
If the client receives an unsolicited response (one not corresponding
|
|
|
|
to a previously issued request) which contains an undesired object, it
|
|
|
|
should send a cancel request, even if the response has completed.
|
|
|
|
This allows the server to gain better feedback to improve its prediction.
|
|
|
|
|
|
|
|
In addition to canceling a request, it is also possible to issue a
|
|
|
|
suspend request. This will suspend data stream until it is resumed or
|
|
|
|
canceled by either the server or the client. This allows a browser to
|
|
|
|
briefly interrupt the transfer of, for example, a set of inline
|
|
|
|
images, if the user switches to a different page, and then resume them if
|
|
|
|
the first page is revisited.
|
|
|
|
|
|
|
|
2.1.2.5 Connection Shutdown.
|
|
|
|
|
|
|
|
The client may close the connection at any time. The client should
|
|
|
|
send a shutdown request, but is not obliged to do so. The server may
|
|
|
|
also shut down the connection at any time. If requests were pending,
|
|
|
|
then the server must send a shutdown request; otherwise it should send
|
|
|
|
a shutdown request.
|
|
|
|
|
|
|
|
|
|
|
|
2.2 Negotiation Model.
|
|
|
|
|
|
|
|
2.2.1 Basic Concepts.
|
|
|
|
|
|
|
|
HTTP/1.0 handles negotiation by sending every possible option
|
|
|
|
supported by the client in every single request. This information
|
|
|
|
makes up 95% of the size of most HTTP requests, and can take nearly a
|
|
|
|
second to send over a dialup connection. Because HTTP-NG uses a long
|
|
|
|
lived connection, this information can be saved and reused to avoid
|
|
|
|
this overhead. HTTP-NG also attempts to reduce the amount of
|
|
|
|
information that must be sent before real requests can be
|
|
|
|
processed. This is achieved by assigning simple identifiers to
|
|
|
|
potentially quite large option strings; for example, a paramaterised
|
|
|
|
type for SGML might include a field to identify the DTD. This string
|
|
|
|
may be tens of bytes long; by defining an intentifier for this type,
|
|
|
|
the type can be referenced with just a few bytes.
|
|
|
|
|
|
|
|
2.2.2 Contexts.
|
|
|
|
|
|
|
|
All options in HTTP-NG are stored in a CONTEXT. There can be several
|
|
|
|
contexts defined for a single connection; if several users are
|
|
|
|
accessing a server through a single proxy, each user would have a
|
|
|
|
separate context.
|
|
|
|
|
|
|
|
2.2.3) Defined Profiles
|
|
|
|
|
|
|
|
Contexts can be initialised from a named profile. Profiles are named by a
|
|
|
|
URL- typically this will be well known standard profile; HTTP-NG also allows
|
|
|
|
contexts to be saved, allowing negotiation to be skipped for commonly used
|
|
|
|
servers.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
LoadProfile http://w3.org/ng/profile-default
|
|
|
|
|
|
|
|
2.2.4) Declaring Vocabulary
|
|
|
|
|
|
|
|
Option values can be declared by assigning them an identifier. These values
|
|
|
|
can have complex structure- a text format is used here for expository purposes.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
Define 0 text/html
|
|
|
|
Define 1 SGML {
|
|
|
|
DTD [html dtd fpi]
|
|
|
|
}
|
|
|
|
Define 2 DES {
|
|
|
|
Keys 3
|
|
|
|
Mode CBC E-D-E
|
|
|
|
}
|
|
|
|
|
|
|
|
2.2.6) Defining Sets and Lists
|
|
|
|
|
|
|
|
Values can be gathered together to form Sets. These can be used
|
|
|
|
to express lists of alternatives and their relative preference. Items in
|
|
|
|
a set are of equal preference; items in a list are in decending order of
|
|
|
|
preference. Sets and lists can be made up of other sets and lists.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
Define 0 image/gif
|
|
|
|
Define 1 text/plain
|
|
|
|
Define 2 text/html
|
|
|
|
Define 3 image/jpeg
|
|
|
|
|
|
|
|
Define-Set 4 { 0,1}
|
|
|
|
Define-Set 5 { 2,3}
|
|
|
|
Define-List 6 {4,5}
|
|
|
|
|
|
|
|
2.2.5) Setting Variables
|
|
|
|
|
|
|
|
These sets and values are not much use unless they can actually be associated
|
|
|
|
with some useful aspect of the protocol. HTTP-NG divides these uses into two
|
|
|
|
types: variables, which represent the attributes and capabilities of the
|
|
|
|
party, and options, which define whether or not the party wishes those
|
|
|
|
capabilities to be used.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
Set-Variable "accept types" 6
|
|
|
|
Set-Variable "user name" [email protected]
|
|
|
|
|
|
|
|
2.2.6) Setting Options
|
|
|
|
|
|
|
|
Options are features which the application may or may not wish to use.
|
|
|
|
HTTP-NG allows the client and server to specific options and their level
|
|
|
|
of preference. These levels are: forbid, allow, prefer, and require. For
|
|
|
|
example, suppose a client is at the end of a slow link. It may wish to
|
|
|
|
indicate a preference to the server for compressed data, as bandwidth is
|
|
|
|
scarer than CPU time. The client would define a list of supported compression
|
|
|
|
algorithms, and indicate a "use-compression" level of prefer.
|
|
|
|
Over a faster link, the same client might reduce that level preference to accept,
|
|
|
|
indicating to the server that it can accept compressed documents, but does
|
|
|
|
not prefer them to uncompressed docs.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
Define 0 compress
|
|
|
|
Define 1 gzip
|
|
|
|
Define-List 2 {1,0}
|
|
|
|
Set-Variable "compressors" 2
|
|
|
|
Set-Option "use-compression" prefer
|
|
|
|
|
|
|
|
2.2.7 Please Negotiate Request.
|
|
|
|
|
|
|
|
Because the negotiation process is incremental, there needs to be a
|
|
|
|
way for each party to request that certain parameters be negotiated.
|
|
|
|
HTTP-NG handles this via the please negotiate request.
|
|
|
|
|
|
|
|
There are two forms of this request; the first form simply requests
|
|
|
|
that the other party offer an unspecified value for an option or
|
|
|
|
variable. The second form requests that the value the one of several
|
|
|
|
included in the request.
|
|
|
|
|
|
|
|
Please negotiate can take place at any time; if a request would have
|
|
|
|
been failed due to incompatible options, the server can try to
|
|
|
|
negotiate extra values instead of having to fail the request. The
|
|
|
|
client can also issue this request if it wishes to obtain information
|
|
|
|
about the server which the server has not offered (for example,
|
|
|
|
implementation names and versions).
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
Please-Negotiate "user name"
|
|
|
|
Please-Negotiate "will-sign" required
|
|
|
|
|
|
|
|
2.3 Metainformation Model.
|
|
|
|
|
|
|
|
The metainformation model used in HTTP-NG is more flexible than that
|
|
|
|
in http. In addition to the standard tags needed for general
|
|
|
|
operation (content-type, content-length, etc.), HTTP-NG allows
|
|
|
|
additional metainformation to be added.
|
|
|
|
|
|
|
|
HTTP-NG takes advantage of existing standards for document description
|
|
|
|
by tagging such extended metainformation with the corresponding tags
|
|
|
|
from USMARC. This tag set was chosen because it is the standard most
|
|
|
|
familiar to indexing professionals, who are the people most likely to
|
|
|
|
be preparing such metainformation.
|
|
|
|
|
|
|
|
2.4 Security Model.
|
|
|
|
|
|
|
|
The security in HTTP-NG is patterned after that in S-HTTP-an extra
|
|
|
|
method is defined as a wrapper around the message to be secured. This
|
|
|
|
wrapper contains optional information about the referenced URL,
|
|
|
|
together with parameters for the negotiated security mechanisms, and
|
|
|
|
the secured message itself. This message can either be an HTTP-NG
|
|
|
|
operation, or an octet string containing an operation in some encoded
|
|
|
|
form.
|
|
|
|
|
|
|
|
HTTP-NG can also be used with a transport level encryption scheme;
|
|
|
|
this mode of operation is not discussed in this document.
|
|
|
|
|
|
|
|
2.4a Data Model.
|
|
|
|
|
|
|
|
In order to make it easier to use HTTP-NG over different transport
|
|
|
|
layers, object data is kept separate from control information. This
|
|
|
|
object data is referenced by control messages either as a session
|
|
|
|
identifier, or as a fully qualified URL. These referenced streams
|
|
|
|
contain only the object data.
|
|
|
|
|
|
|
|
2.5.2 Initial Method Set
|
|
|
|
|
|
|
|
Although there may eventually be other methods defined, this draft of
|
|
|
|
the specification only defines a small method set.
|
|
The basic operations (get and put) have simplified variants defined in
this draft. These are specified to make it easier to prepare basic
implementations quickly, whilst allowing as much code as possible to
be shared with the full version.
2.5.2.1 Simple Get.
The Simple Get request allows the client to request a document from
the server, and offers approximately the same level of functionality
as the HTTP/1.0 GET request. The simple get request takes the
following parameters:
url The URL which is being requested.
meta-information-only If set, only send metainformation.
if-modified-since (OPTIONAL) Only send document if it has been
modified since this date.
referer The URL of the object which refered to this
object, if any. This field is mandatory for
all non-base accesses.
The simple get response contains the following fields:
content-length (OPTIONAL) The size of the object being returned.
created (OPTIONAL) The date this object was created.
modified (OPTIONAL) The date this object was last modified.
content-type The type of this object.
content-language (OPTIONAL) The language in which this document is written.
data (OPTIONAL) The contents of this object.
2.5.2.2 Get.
The full get request extends the simple form with the following
fields:
range (OPTIONAL) A range of data within the object
metainfo-fields The metainformation to be returned.
variant-spec The variant of the object to return.
The full get response is derived from the basic response with the
addition of the following fields:
metainformation The full set of requested metainformation.
2.5.2.3 Simple Put.
[XXX]
2.5.2.4 Put.
[XXX]
2.5.2.5 Secured Message.
Secured Message is used to carry a message with associated security
attributes. The secured message contains the following parameters:
url (OPTIONAL) The URL which the secured message will
apply to. This information is used
for routing by proxy servers.
scheme The security scheme to be used.
scheme-parameters Scheme specific data.
message Either an HTTP-NG operation or an
octet string containing the real message.
2.5.2.6 HTTP-TOS Request.
This request is used to carry an original http request. The request
or response itself is carried on a data stream; this is to make sure
that the control channel is not tied up by large requests or
responses, and to keep the entire request together to make it easier
to relay such requests.
This operation is provided for two reasons; the first is to make it
easier for existing applications to be converted to HTTP-NG. The
second is to make it possible to gateway S-HTTP requests, which
require the original message to be present for checksum purposes.
3) Data Structures And Message Formats.
3.1) Useful types
A few general purpose types used to make the rest of the spec clearer.
SHORT ::= INTEGER(0..64K)
DATE ::= SEQUENCE {
seconds INTEGER,
microseconds INTEGER
}
URL ::= OCTET STRING
Data ::= CHOICE {
sessionID INTEGER,
url URL
}
Value ::= CHOICE {
string OCTET STRING,
integer INTEGER,
taggedList taggedList,
referencedValue ReferencedValue
}
TaggedList ::= SEQUENCE OF SEQUENCE {
tag Value,
value Value
}
ReferencedValue ::= SEQUENCE {
context INTEGER OPTIONAL,
identifier INTEGER
}
3.2) HTTPMessage
HTTPMessage ::= SEQUENCE {
messageId INTEGER,
contextId INTEGER,
with TaggedList OPTIONAL,
operation Operation
}
Operation ::= CHOICE {
initaliseRequest [0] InitialiseRequest,
initaliseResponse [1] InitialiseResponse,
genericErrorResponse [2] GenericErrorResponse,
negotiationRequest [3] NegotiationRequest,
negotiationResponse [4] NegotiationResponse,
pleaseNegotiateRequest [5] PleaseNegotiateRequest,
pleaseNegotiateResponse [6] PleaseNegotiateResponse,
securedMessage [7] SecuredMessage,
cancelOrSuspendStreamRequest [8] CancelOrSuspendStreamRequest,
cancelOrSuspendStreamResponse [9] CancelOrSuspendStreamResponse,
resumeRequest [10] ResumeRequest
http-tos [11] HTTP-TOS
}
3.3) Initialise
InitialiseRequest ::= SEQUENCE {
protocolVersion INTEGER,
protocolModel ENUMERATION {sync(0),interleave(1), preemptive(2)},
clientSupport BIT STRING,
serverSupport BIT STRING
}
InitialiseResponse ::= SEQUENCE {
result BOOLEAN,
protocolVersion INTEGER,
protocolModel ENUMERATION {sync(0),interleave(1), preemptive(2)},
clientSupport BIT STRING,
serverSupport BIT STRING
}
3.4) SimpleGet
SimpleGetRequest ::= SEQUENCE {
url URL,
meta-information-only BOOLEAN,
if-modified-since DATE OPTIONAL,
referer URL OPTIONAL
}
SimpleGetResponse ::= SEQUENCE {
metaInfo BasicMetaInformation,
data Data OPTIONAL
}
BasicMetaInformation ::= SEQUENCE {
content-length INTEGER OPTIONAL,
created DATE OPTIONAL,
modified DATE OPTIONAL,
content-type Value,
content-language Value OPTIONAL
}
3.5) SimplePut
[XXX]
3.6) Get
GetRequest ::= SEQUENCE {
url URL,
meta-information-only BOOLEAN,
if-modified-since DATE OPTIONAL,
referer URL OPTIONAL,
range Range OPTIONAL,
metainfo-fields Metainfo-fields,
variant-spec TaggedList OPTIONAL
}
Metainfo-fields ::= SEQUENCE {
content-length BOOLEAN,
content-language BOOLEAN,
created BOOLEAN,
modified BOOLEAN,
inline BOOLEAN,
inlinemetainfo Metainfo-fields OPTIONAL,
extended BOOLEAN,
extended-fields SEQUENCE OF Value OPTIONAL
}
GetResponse ::= SEQUENCE {
basicMetaInfo basicMetaInformation,
data Data OPTIONAL,
extendedMetaInformation TaggedList OPTIONAL,
inlines SEQUENCE OF SEQUENCE {
url URL,
basicMetaInfo basicMetaInformation OPTIONAL,
extendedMetaInformation TaggedList OPTIONAL
} OPTIONAL
}
3.7) Put
3.8) Negotiation
NegotiationRequest ::= SEQUENCE OF NegotationOperation
NegotiationOperation ::= CHOICE {
delete-context [0] NULL,
load-profile [1] URL,
save-profile [2] URL,
define-value [3] SEQUENCE {
tag INTEGER,
value Value
},
define-set [4] SEQUENCE {
tag INTEGER,
value BIT STRING
},
define-list [5] SEQUENCE {
tag INTEGER,
value SEQUENCE OF INTEGER
},
delete-value [6] INTEGER,
set-variable [7] SEQUENCE {
variable-name OCTET STRING,
value Value
}
set-option [8] SEQUENCE {
option-name OCTET-STRING,
level ENUMERATION {forbid(0), allow(1),prefer(2),
require(3)}
}
}
NegotiationResponse ::= SEQUENCE OF BOOLEAN
PleaseNegotiateRequest ::= SEQUENCE OF SEQUENCE {
field Value,
values SEQUENCE OF Value OPTIONAL,
level ENUMERATION {forbid(0), allow(1),prefer(2),require(3)} OPTIONAL
}
PleaseNegotiateResponse ::= NULL
3.9) SecureMessage
SecuredMessage ::= SEQUENCE {
url URL OPTIONAL,
scheme Value,
scheme-parameters TaggedList,
message CHOICE {
operation Operation,
encrypted OCTET STRING
}
}
3.10) CancelOrSuspendStream.
CancelOrSuspendStreamRequest ::= SEQUENCE {
suspend BOOLEAN,
stream-to-cancel Data
}
CancelOrSuspendStreamResponse ::= SEQUENCE {
suspended BOOLEAN
}
ResumeRequest ::= Data
ResumeResponse ::= NULL
3.11 Generic Error.
GenericError ::= SEQUENCE {
result-code INTEGER,
extra-info TaggedList,
message OCTET STRING OPTIONAL,
}
3.12 HTTP-TOS.
HTTP-TOS ::= SEQUENCE {
cache-headers BOOLEAN,
request-stream Data
}
4.0) Security Issues
Appendix A.
Standard Options And Variables
Variables:
Accept-Types List of Acceptable content types
Accept-Languages List of Acceptable content languages
Accept-Encodings List of Acceptable content encodings
Compressors List of Acceptable compression formats
Privacy-Domains List of supported Privacy Domains
User-Name Users name
Implementation-Name Name of implementation
Options:
Use-Compression Should compression be used
Appendix B.
Standard Error Codes.
[same as http classic for now]
404 - Document not found
500 - Unspecified error
|