Fast HTTP - a hyper-text transfer protocol for tommorows networks.
Simon E Spero <ses%tipper@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 29 Jun 1994 22:10:17 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406291752.AA01176@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: ses%tipper@tipper.oit.unc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Simon E Spero <ses%tipper@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Fast HTTP - a hyper-text transfer protocol for tommorows networks.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
Hi guys -
I haven't had time to write this up properly, as I've been
working getting the BGI based server working properly with Slow HTTP :-);
there's been some interest shown, so I figured I'd post a sketch description,
plus the working draft of the ASN.1.
It probably won't make much sense to anybody yet, but it should become
clearer over time.
Fast HTTP
---------
Service description:
Fast HTTP (FHTTP) is an applications protocol for transfering
hypermedia objects. It is based on the existing HTTP protocol, but
uses a different encoding for request and response messages, together
with a different transaction model. This protocol is designed for use
over high relative-latency networks, although certain features also
make it suitable for use over low bandwidth connections.
FHTTP operates over reliable connection oriented transports such as
TCP; modifications for use over unreliable connection-less transports
like UDP are possible, but are not addressed in this note.
Protocol operation:
All FHTTP transactions are asynchronous.
Once a transport level connection is established, the client sends an
initialise request; when a server recieves this request, it responds
with an initialise response. The server may send other requests before
recieving the response; however the server must return the initialise
response message before any other responses.
Once the initialisation stage has been completed, the client and
server exchange requests and responses. Each message is labeled with a
16 bit message identifier; client initiated messages should use even
numbered message ids; server initiated messages odd numbered ones.
The only request/response pair currently defined is 'GET'. A GET
request contains a list of one or more URIs to be retrieved. The
server can split a single object into multiple responses, each
containing part of the whole; this allows dynamically created
objects to be generated and transmitted on the fly. Responses for more
than one object can be interleaved.
In addition to objects corresponding to those listed in the GET
request, the server may transmit a certain number of objects that
were not requested, corresponding to objects which it believes the
server is likely to request in the immediate future. The canonical
example for this is the retrieval of bitmapped graphics embedded in an
HTML page; however it can also be used when certain links on a page
are followed with very high probability.
If a client recieves a GET response corresponding to an unsolicited
object, and determines that the object is indeed needed, it should
then transmit a request corresponding to that object (i.e. the
response is transmitted before the request). If the object is
definitely un-needed, the client should issue a cancel request.
---
ASN.1
-----
FHTTP DEFINITIONS ::=
BEGIN
HTTPMessage ::= [APPLICATION 0] IMPLICIT SEQUENCE {
messageId INTEGER (0..65535),
method CHOICE {
initRequest [0] InitRequest,
initResponse [1] InitResponse,
getRequest [2] GetRequest,
getResponse [3] GetResponse,
putRequest [4] PutRequest,
putResponse [5] PutResponse,
cancelRequest [6] CancelRequest,
reserved-1 [7] NULL,
reserved-2 [8] NULL,
reserved-3 [9] NULL,
reserved-4 [10] NULL,
reserved-5 [11] NULL,
reserved-6 [12] NULL,
reserved-7 [13] NULL,
reserved-8 [14] NULL,
reserved-9 [15] NULL
}
}
InitRequest ::= SEQUENCE {
version INTEGER(0..255),
maxUnsolicited INTEGER,
accept Accept OPTIONAL,
authentication Authentication OPTIONAL
}
Accept ::= SEQUENCE {
standardTypes BIT STRING OPTIONAL, -- LENGTH MINIMUM 32 MAXIMUM 32
otherTypes SEQUENCE OF SEQUENCE {
typeName VisibleString,
penalty INTEGER (0..65535)
} OPTIONAL
}
Authentication ::= CHOICE {
simple [0] SEQUENCE {
name OCTET STRING,
password OCTET STRING
},
other [1] SEQUENCE {
schemeId VisibleString,
tokens SEQUENCE OF OCTET STRING
}
}
InitResponse ::= SEQUENCE {
version INTEGER(0..255),
status BOOLEAN,
message OCTET STRING OPTIONAL
}
GetRequest ::= SEQUENCE {
uri [0] OCTET STRING,
accept [1] Accept OPTIONAL,
headersOnly [2] BOOLEAN DEFAULT FALSE,
checkOut [3] BOOLEAN DEFAULT FALSE
}
GetResponse ::= SEQUENCE {
status INTEGER,
uri [0] OCTET STRING OPTIONAL ,
headers Headers OPTIONAL,
more BOOLEAN,
data OCTET STRING OPTIONAL
}
CancelRequest ::= INTEGER
Headers ::= NULL
PutRequest ::= NULL
PutResponse ::= NULL
END