HTTP (or Hypertext Transfer Protocol according to AbbreviationFinder) is the protocol used in every transaction on the World Wide Web, or WWW. Through HTTP, clients and servers dynamically determine the format of documents, allowing them to use non-standard data formats for data exchange. If the recipient does not have a way to view or access the data, they can download a plug-in program that allows them to receive the content.
HTTP headers can contain information about objects that your application transmits over the web. With the information in the headers, Client-Server applications negotiate formats that they can use to transfer the objects. If they don’t recognize the information in the header, they ignore it. Therefore, you can test new protocols on the Web without compromising the integrity of HTTP. In addition, the protocol is text-based so it is readable and does not need decoding.
History
HTTP was developed by the World Wide Web Consortium and the Internet Engineering Task Force, a collaboration that culminated in 1999 with the publication of a series of RFCs, the most important of which is RFC 2616, which specifies version 1.1. HTTP defines the syntax and semantics used by the software elements of the web architecture (clients, servers, proxies) to communicate.
It is a transaction-oriented protocol and follows the request-response scheme between a client and a server. The client making the request (a web browser or a spider) is known as a ” user agent “. The information transmitted is called a resource and is identified by a uniform resource locator (URL). The resources can be files, the result of the execution of a program, a query to a database, the automatic translation of a document, etc.
HTTP is a stateless protocol, that is, it does not store any information about previous connections. Web application development frequently needs to maintain state. Cookies are used for this, which is information that a server can store on the client system. This allows web applications to institute the notion of “session”, and also allows users to be tracked as cookies can be stored on the client indefinitely.
HTTP transactions
A transaction P consists of a header, optionally followed by a blank line and some data. The header will specify things like the action required from the server, or the type of data returned, or the status code.
The use of header fields sent in TP trans gives great flexibility to the protocol. These fields allow descriptive information to be sent in the transaction, thus allowing user authentication, encryption and identification.
A header is a block of data that precedes the information itself, which is why it is often referred to as metadata because it has data about the data.
If header lines are received from the client, the server places them in the CGI environment variables with the prefix HTTP_ followed by the header name. Any dash (-) character in the header name is converted to “_” characters.
The server can exclude any headers that are already processed, such as Authorization, Content-type, and Content-length. The server may choose to exclude some or all of the headers if including them exceeds some system environment limit. Examples of this are the HTP_ACPT and HTP_R_AEN variables.
- HT_AEP ‘. The MIME types that the client will accept, given the HTTP headers. Other protocols may need to obtain this information from elsewhere. Items in this list must be separated by a comma, as the HTTP specification says: type, type.
- HTT_USR_AET. The browser that the client uses to make the request. The general format for this variable is: software / library version / version.
The server sends the client:
- A status code that indicates whether the request was successful or not. Typical error codes indicate that the requested file was not found, that the request was not successful, or that authentication is required to access the file.
- The information itself. Because HTTP allows you to send documents of all types and formats, it is ideal for transmitting multimedia, such as graphics, audio and video. This freedom is one of the biggest advantages of HTTP.
- Information about the object that is returned.
Note that the list is not a complete list of the header fields and that some of them only make sense in one direction.
Versions
HTTP has gone through multiple versions of the protocol, many of which are backward-compatible. RFC-2145 describes the use of HTTP version numbers. The client tells the server at the beginning of the request what version it uses, and the server uses the same or an earlier version in its response.
- 9
Obsolete. It supports only one command, GET, and also does not specify the HTTP version number. It does not support headers. Since this version does not support POST, the client cannot send much information to the server.
- HTTP / 1.0 (May 1996)
This is the first revision of the protocol that specifies its version in communications, and it is still widely used, especially on proxy servers.
- HTTP / 1.1 (June 1999)
Current version; persistent connections are on by default and work fine with proxies. It also allows the client to send multiple requests at the same time (pipelining) which makes it possible to eliminate the Round-Trip delay time for each request.
- HTTP / 1.2
The first 1995 drafts of the document PEP – an Extension Mechanism for HTTP (which proposes the Protocol Extension Protocol, abbreviated PEP) were made by the World Wide Web Consortium and sent to the Internet Engineering Task Force. The PEP was initially intended to become a distinctive range of HTTP / 1.2. [3] In later drafts, however, the reference to HTTP / 1.2 was removed. HTTP Extension Framework, largely includes PEP. It was published in February of 2000.
