Hypertext Transfer Protocol

The Hypertext Transfer Protocol (in English, Hypertext Transfer Protocol, abbreviated HTTP) is the protocol for communication that allows the transfer of information through files (XML, HTML…) on the World Wide Web. It 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 specifying version 1.1. HTTP defines the syntax and semantics that software elements of the web architecture (clients, servers, proxies) use to communicate.

HTTP is a stateless protocol, so it does not save any information about previous connections. Web application development frequently needs to maintain state. For this, cookies are used, 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 user tracking, since cookies can be stored on the client indefinitely.

Description

It is a transaction-oriented protocol and follows the request-response scheme between a client and a server. The client (usually called a "user agent") makes a request by sending a message, in a certain format, to the server. The server (which is commonly called a web server) sends you a response message. Examples of clients are web browsers and web spiders (also known by their English term, webcrawlers).

Messages

HTTP messages are in plain text, which makes it more readable and easier to debug. However, this has the drawback of making the messages longer. The messages have the following structure:

• Initial line (end with car return and line jump) with
  • For requests: the action required by the server (request method) followed by the resource URL and the HTTP version supported by the client.
  • For answers: The version of the used HTTP followed by the response code (which indicates what happened with the request followed by the resource URL) and the phrase associated with that return.
• The headers of the message that end with a blank line. They're metadata. These headers give great flexibility to the protocol.
• Message body. It's optional. Its presence depends on the previous line of the message and the type of resource to which the URL refers. Typically it has data that are exchanged client and server. For example, for a request it might contain certain data that you want to send to the server for processing. For an answer it might include the data the customer has requested.

Request methods

An HTTP order using telnet. The order (request), response headers (response headers) and the body of the answer (response body) are highlighted.

HTTP defines a predefined set of request methods (sometimes referred to as "verbs") that can be used. The protocol has flexibility to add new methods and thus add new functionalities. The number of request methods has been increased as the versions progressed. This list includes the methods added by WebDAV.

Each method indicates the action you want performed on the identified resource. What this resource represents depends on the server application. For example, the resource may correspond to a file that resides on the server.

GET

The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true for some other HTTP methods.)

HEAD

RFC 2616. Requests a response identical to what would correspond to a GET request, but the response body is not returned. This is useful to be able to retrieve the metadata from the response headers, without having to transport all the content.

POST

RFC 2616. Sends data to be processed by the resource identified in the URL of the request line. The data will be included in the body of the request. At a semantic level, it is oriented to create a new resource, whose nature will be specified by the Content-Type header. Examples:

• For encoded forms like a URL (although they travel in the body of the request, not in the URL): application/x-www-form-urlencoded
• For blocks to upload, e.g. files: multipart/form-data
• In addition to the above, there is no mandatory standard and could also be others as text/plain, application/json, application/octet-stream...

PUT

(RFC 2616) Sends data to the server, but unlike the POST method, the URI of the request line does not refer to the resource that will process it, but identifies the data itself (see detailed explanation in the RFC). Another difference with POST is semantics (see REST): while POST is oriented towards creating new content, PUT is more oriented towards updating it (although it could also create it).

Example:

PUT /path/filename.html HTTP/1.1

DELETE

RFC 2616. Deletes the specified resource.

TRACE

(RFC 2616) This method asks the server to include in the response all the data it receives in the request message. It is used for debugging and diagnostic purposes as the client can see what arrives at the server and thus see everything that is added to the message by intermediate servers

OPTIONS

RFC 2616. Returns the HTTP methods that the server supports for a specific URL. This can be used to check the functionality of a web server by request instead of a specific resource.

CONNECT

RFC 2616. It is used to find out if you have access to a host, the request does not necessarily reach the server, this method is mainly used to find out if a proxy gives us access to a host under special conditions, such as & #34;currents" encrypted two-way data stream (as required by SSL).

PATCH

(RFC 5789). Its function is the same as PUT, which completely overwrites a resource. It is used to partially update one or several parts. It is also intended for use with proxy.

MOVE

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

MERGE

RFC 3253

UPDATE

RFC 3253

LABEL

RFC 3253

Response Codes

The response or return code is a number indicating what happened with the request. The rest of the content of the response will depend on the value of this code. The system is flexible and in fact the list of codes has been increasing in order to adapt to changes and identify new situations. Each code has a specific meaning. However, the number of codes is chosen in such a way that, depending on whether it belongs to one hundred or another, the type of response given by the server can be identified:

• 1xx format codes: Information responses. It indicates that the request has been received and is being processed.
• 2xx format codes: Correct answers. It indicates that the request has been properly processed.
• 3xx format codes: Redirect responses. Indicates that the customer needs to perform more actions to end the request.
• Codes with 4xx format: Errors caused by the customer. It indicates that there has been an error in processing the request because the client has done something wrong.
• 5xx format codes: Errors caused by the server. It indicates that there has been an error in processing the request because of a fault on the server.

Headers

This is the metadata that is sent in HTTP requests or responses to provide essential information about the current transaction. Each header is specified by a header name followed by a colon, a blank space, and the header value followed by a carriage return followed by a line feed. A blank line is used to indicate the end of the headers. If there are no headers the blank line should remain.

Headers give the protocol great flexibility, allowing you to add new functionality without having to change the base. That is why as the HTTP versions have been happening, more and more allowed headers have been added.

Headers can contain metadata that has to be processed by the client (eg, in response to a request, the type of content it contains can be indicated), by the server (eg, types of representations acceptable to the client of the content it contains). requests) or by intermediaries (eg how to manage caching by proxies)

Depending on the type of message in which a header can go, we can classify them into request headers, response headers and headers that can go in both a request and a response.

We can classify the headers according to their function. For example:

• Heads that indicate the accepted capabilities of the message: Accept (indicates MIME accepted), Accept-Charset (indicates the code of characters accepted), Accept-Encoding (indicates the accepted compression method), Accept-Language (indicates the accepted language), User-Agent (to describe the client) Server (indicates the type of server), Allow (methods allowed for appeal)
• Heads describing the content: Content-Type (indicates MIME of content), Content-Length (length of message), Content-Range, Content-Encoding, Content-Language, Content-Location.
• Heads that refer to URIs: Location (indicating where the content is), Refer (Indicates the origin of the request.)
• Heads that save transmissions: Date (date of creation), If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range, Expires, Last-Modified, Cache-Control, Via, Pragma, Etag, Age, Retry-After.
• Cookies control heads: Set-Cookie, Cookie
• Heads for authentication: Authorization, WW-Authenticate
• Heads to describe communication: Host (indicating target message machine), Connection (indicates how to establish the connection)
• Other: Range (to download only parts of the resource) Max-Forward (limit of headers added to TRACE).

HTTP Dialog Example

To get a resource with the URL http://www.example.com/index.html

1. A connection is opened in port 80 of the host www.example.com. The 80 port is the predefined port for HTTP. If the XXXX port is to be used, it should be encoded in the URL of the form http://www.example.com:XXXX/index.html
2. A message is sent in the following style:

 GET /index.html HTTP/1.1
Host: www.example.com
Referer: www.google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Connection: keep-alive
[White line]

The server response consists of headers followed by the requested resource, in the case of a web page:

HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221

html lang="eo"
≤2
Δmeta charset="utf-8"
≤350 %%%% %% %%%%%%%
≤2
▪
≤1 taxPágina principal de tuHost PREMIUM/h1
(Content)
.
.
.
▪
◊

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 which version it is using, and the server uses the same or an earlier version in its response.

0.9 (launched in 1991)

Obsolete. It supports only one command, GET, and also does not specify the HTTP version number. No headers. Since this version does not support POST, the customer cannot send much information to the server.

HTTP/1.0 (May 1996)

This is the first review of the protocol that specifies your version in communications, and is still widely used, especially on proxy servers. Allows the GET, HEAD and POST request methods.

HTTP/1.1 (June 1999)

Most currently used version;^{[chuckles]required]} Persistent connections are activated by default and work well with proxies. It also allows the customer to send multiple requests at once for the same connection (pipelining) which makes it possible to remove the time of Round-Trip delay for each request.

HTTP/1.2 (February 2000)

The first drafts of 1995 PEP — an Extension Mechanism for HTTP (which proposes the Protocol Extension Protocol, abbreviated PEP) was 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. In subsequent drafts, however, the reference to HTTP/1.2 was deleted. RFC 2774 (experimental), HTTP Extension Frameworkincludes PEP to a large extent. It was published in February 2000.

HTTP/2 (May 2015)

In 2012, the first drafts of the new version of HTTP (HTTP/2) appeared. This new version does not modify the semantic application of https (all basic concepts continue to be unchanged). Its improvements focus on how data and transport are packaged. For example, it adds the use of a single connection, the compression of headers or the 'server push' service. The most important explorers only support HTTP 2.0 on TLS using the ALPN extension that requires TLSv1.2 or higher.

HTTP/3 (October 2018)

HTTP/3 is the proposed successor to HTTP/2, which is already in use on the web, using UDP instead of TCP for the underlying transport protocol. Like HTTP/2, it is not obsolete in earlier major versions of the protocol. HTTP/3 support was added to Cloudflare and Google Chrome in September 2019, and can be enabled in stable versions of Chrome and Firefox.