The definition of this protocol is in the public domain (see policy ).
The protocol uses the normal internet-style telnet protocol style on a TCP-IP link. The following describes how a client acquires a (hypertext) document from an HTTP server, given an HTTP document address .
If the port number is not specified, 80 is always assumed for HTTP.
The server accepts the connection.
Note: HTTP currently runs over TCP, but could run over any connection-oriented service. The interpretation of the protocol below in the case of a sequenced packet service (such as DECnet(TM) or ISO TP4) is that that the request should be one TPDU, but the response may be many.
This request consists of the word "GET", a space, the document address , omitting the "http:, host and port parts when they are the coordinates just used to make the connection. (If a gateway is being used, then a full document address may be given specifying a different naming scheme).
The search functionality of the protocol lies in the ability of the addressing syntax to describe a search on a named index .
A search should only be requested by a client when the index document itself has been descibed as an index using the ISINDEX tag .
Lines shall be delimited by an optional carriage return followed by a mandatory line feed chararcter. The client should not assume that the carriage return will be present. Lines may be of any length. Well-behaved servers should retrict line length to 80 characters excluding the CR LF pair.
The format of the message is HTML - that is, a trimmed SGML document. Note that this format allows for menus and hit lists to be returned as hypertext. It also allows for plain ASCII text to be returned following the PLAINTEXT tag .
The message is terminated by the closing of the connection by the server.
Well-behaved clients will read the entire document as fast as possible. The client shall not wait for user action (output paging for example) before reading the whole of the document. The server may impose a timeout of the order of 15 seconds on inactivity.
Error responses are supplied in human readable text in HTML syntax. There is no way to distinguish an error response from a satisfactory response except for the content of the text.
The client may abort the transfer by breaking the connection before this, in which case the server shall not record any error condition.
Requests are idempotent . The server need not store any information about the request after disconnection.
_________________________________________________________________
Tim BL