Everybody uses this protocols but not all the people knows the amount of functions that uses.

The meaning of the achronym is Hyper Text Transfer Protocol.  It is a layer 7(Application) protocol and uses 80 port.

HTTP is a request-response standard typical of client-server computing. In HTTP, web browsers or spiders typically act as clients, while an application running on the computer hosting the web site acts as a server. The client, which submits HTTP requests, is also referred to as the user agent. The responding server, which stores or creates resources such as HTML files and images, may be called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.

HTTP versions:

HTTP/1.0. Uses a separate connection to the same server for every document that is requested. After a request/response comunication connection is closed.

HTTP/1.1. Uses same connection to download for instance.keep-alive-mechanism was introduced, where a connection could be reused for more than one request.HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.

An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request. It establishes a TCP connection to a particular port on a host . An HTTP server listening on that port waits for a client’s request message. Upon receiving the request, the server sends back a status line, such as “HTTP/1.1 200 OK”, and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.

HTTP messages:

1xx Information

100 Continue

101 Switching protocols

2xx Successful

200 OK

201 Created


203 Non-authoritative information

204 No Content

205 Reset content

206 Partial content

3xx Redirection

300 Multiple choices

301 Moved permanently

302 Found

303 See other

304 Not modified

305 Use proxy

306 Unused

307 Temporary redirect

4xx Client Error

400 Bad request

401 Unauthorized

402 Payment required

403 Forbidden

404 Not found

405 Method not allowed

406 Not acceptable

407 Proxy authentication required

408 Request timeout

409 Conflict

410 Gone

411 Lengh required

412 Precondition failed

413 Request entity too large

414 Request-url too long

415 Unsuported media type

416 Requested range not satisfiable

417 Expectation failed

5xx Server Error

500 Internal server error

501 Not implemented

502 Bad gateway

503 Service unavailable

504 Gateway timeout

505 HTTP version not supported

Request methods

GET –The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

HEAD –The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.

POST –The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

PUT –The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

DELETE – Requests that the origin server delete the resource identified by the Request-URI.

TRACE – To invoke a remote, application-layer loop- back of the request message.

OPTIONS – Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.

CONNECT – For use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling)

PATCH – Is used to apply partial modifications to a resource.

Safe methods

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application’s state should therefore be considered safe.

By contrast, methods such as POST, PUT and DELETE are intended for actions which may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers, which tend to make requests without regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way, and careless or deliberate programming can just as easily (or more easily, due to lack of user agent precautions) cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server.