RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html below:

HTTP2 -- /HTTP

Last modified 1/7/92 by RC Updates To HTTPThe HTTP protocol implements the WWW data model .

In order to improve the functionality of WWW, the HyperText Transfer Protocol needs to be altered (see also: current HTTP implementation, from version to version, our BNF notation and the original HTTP design ).

A prime concern is that servers must be able to skip data they don't understand. This will guarantee forward compatibility.

RequestAs before, the client sends a request, but may specify additional information. The format of the new request is: Request ::= Get | Put Get ::= GET Udi [CiLang]/VersionNumber CrLf ClientInfo Put ::= PUT Udi [Cilang]/VersionNumber CrLf ClientInfo CrLf DataInfo CrLf [body section] CiLang ::= HTRQ Udi is the Universal Document Identifier.

CiLang specifies the language used to write the ClientInfo and the DataInfo after the GET line. At the moment only HTRQ is defined .

VersionNumber gives the HTTP version being used by the client.

If the protocol version is not specified, the server assumes that the browser uses HTTP version 0.9 (before this update was carried out) (See " From Version to Version ").

GET means retrieve whatever data is identified by the Udi, so where the Udi refers to a data-producing process, or a script which can be run by such a process, it is this data which will be returned, and not the source text of the script or process.

PUT specifies that the data in the body section is to be stored under the supplied Udi, (but see constraint on modification times ).

Where the Udi refers to a data-producing process, PUT is not applicable, and will fail. The process should label its response as non-editable.

[JFG] Beware here of lexical problems like different character sets on client and server, CR/LF conventions, etc. Also, elementary file locking should be provided.

ResponseThe response from the server may be straight HTML (in the case of older servers), or may start with the following syntax: RESPONSE=String HTTPV=VersionNumber CrLf ... String identifies the type of the response, VersionNumber identifies the HyperText Transfer Protocol version being used by the server. Then follows additional information depending on the response type.

The keywords, here in upper case, are case insensitive. Quotes may be ommited where String does not contain special characters (such as spaces).

The response String may have the following values (see data model ):

ERROR: the server encountered an abnormal condition,
FORWARD: the data requested has been assigned a new Udi, the change is permanent. (N.B. this is an optimisation, which must, pragmatically, be included in this definition. Browsers should automatically relink to the new reference, where possible),
REDIRECTION: the data requested actually resides under a different Udi, however, the redirection may be altered on occasion (when making links to these kinds of document, the browser should default to using the Udi of the redirection document, but have the option of linking to the final document),
QUERY: the data is composed of (1) the identification of a server and (2) the algorithm in some arbitrary language, to be passed to the server which will use it to extract the data.
INDEX: the data is the "front page" of a data base, to which further search keys have to be supplied before desired data can be extracted. A search panel has to be put up by the browser. The front page is otherwise a normal HTML document, including the possibilities of containing anchors.
DATA: this is the data requested,
CONFIRMATION: the command transmitted has been successfully completed (PUT command).

Detailed syntax of the response is given in HTRESP .

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3