1. carriage return character. This request consists

1. Introduction HTTP stands for Hyper Text Transfer Protocol. HTTP works at application layer, transfering data for world wide web(www). This protocol was devloped initially by Tim-Berners-Lee at CERN in 1989.Standards development of HTTP was further carried by the Internet Engineering Task Force(IETF) and the World Wide Web Consortium(W3C). HTTP is designed to allow elements inside network to enable communications between clients and servers. A web browser is an example of a client, this list also include the indexing software used by search provide, mobile apps, voice browsers, and other software that accesses, consumes, or displays web content.2. HistoryThe term hypertext was coined by Ted Nelson in 1965 in the Xanadu Project, which was in turn inspired by Vannevar Bush’s 1930s vision of the microfilm-based information retrieval and management “memex” system described in his 1945 essay “As We May Think”.Tim Berners-Lee and his team at CERNare credited with inventing the original HTTP along with HTML and the associated technology for a web server and a text-based web browser. Year HTTP Version1991 0.91996 1.01997 1.12015 2.0The first documented version of HTTP was HTTP V0.9 in 1991. They wanted to improve protocol’s efficency by extending operations, richer meta-information, tied with a security protocol .2.1 HTTP V0.9The Hypertext Transfer protocol originally as implemented by the World Wide Web initaitive software in the prototype released. This was HTTP 0.9 which was subset of the full HTTP protocol. It used TCP-IP link as used in old traditional styled internet. It mainly has 4 steps, Connection, Request, responce, disconnect:Connection The client makes a TCP-IP connection to the domain or IP,at the port number given in the address. The port number for HTTP is 80 by default. The server accepts the connection.Request The client sends a request of a line of ASCII characters terminated by a CR LF pair. A well-behaved server will not require the carriage return character. This request consists of the word “GET”, a space, the document address.Response The response, in ASCII to a simple GET request is a message in hypertext mark-up language  (HTML ). Error are supplied in human readable text in HTML. There is no way to distinguish an error response from a satisfactory response except for the content of the text.Disconnection The connection is disconnected by the server when the whole document has been transferred. Thus, the server do not need to store any information about the request after disconnection.For the new document, client has to repeat the whole process.Status Codes: The values of the numeric status code to HTTP requests are as follows. The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information.Success (2xx)These codes indicate success. The body section if present is the object returned by the request. It is a MIME format object. It is in MIME format, and may only be in text/plain, text/html or one fo the formats specified as acceptable in the request.OK (200) : The request was fulfilled.CREATED (201): This occurs when the webpage is successfully created.Accepted (202): This occurs when the request has been accepted. The further processing takes place afterwards.Partial Information (203) : This states that the information provided is not complete set of metadata.No Response (204):This indicates that server has got request but there is nothing to return the client.Error (4xx, 5xx)The 4xx codes are for cases in which the client have erred, and the 5xx codes for the cases which the server has erred. Bad request (400) : The client request is with bad/wrong syntax to be satisfied.Unauthorized (401) : The parameter passed for authentication have failed to do so.PaymentRequired (402) : The parameter to this message gives a specification of charging schemes acceptable.Forbidden (403) :  The request is for something forbidden. Not found (404) : The server has not found anything matching URI.Internal Error (500) : The server encountered an unexpected condition.Not implemented (501) : The server does not support the facility.Service temporarily overloaded (502) :The server cannot process the request due to a high load.Gateway timeout (503) : This is equivalent to Internal Error 500, the server is waiting for some other service for reply which the server did not receive within the timeout limit.Redirection 3xxThe codes in this section indicate action to be taken by the client in order to fulfill the request.Moved (301) : The data requested has been assigned a new URI.  Browsers should automatically relink to the new reference.Found (302) : The data requested actually resides under a different URL, however, the redirection may be altered on occasion as for “Forward”.Not Modified (304) : If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.2.2 HTTP V1.0HTTP V1.0 is evolved from the original HTTP V0.9. The process leading to HTTP V1.0 involved significant debate and experimentation, but never result to a formal specification. HTTP V1.0 uses many of the constructs defined for MIME. HTTP allows for different use of Internet Media Types than is typically found in Internet mail.HTTP is also used as a protocol for communication between user agents and proxies/gateways.HTTP 0.9:No client profile information is transferred with the query. Future HTTP protocols will be back-compatible with this protocol.This restricted protocol is very simple and may always be used when you do not need the capabilities of the full protocol which is backwards compatible.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 documentaddress .ConnectionThe client makes a TCP-IP connection to the host using the domain name or IP number , and the port number given in the 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.RequestThe client sends a document request consisting of a line of ASCII characters terminated by a CR LF (carriage return, line feed) pair. A well-behaved server will not require the carriage return character.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 document address will consist of a single word (ie no spaces). If any further words are found on the request line, they MUST either be ignored, or else treated according to the full HTTP spec .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 .ResponseThe response to a simple GET request is a message in hypertext mark-up language ( HTML ). This is a byte stream of ASCII characters.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.DisconnectionThe TCP-IP connection is broken by the server when the whole document has been transferred.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.HTTP 1.0 VS HTTP 1.1Persistent connections:HTTP 1.1 also allows you to have persistent connections which means that you can have more than one request/response on the same HTTP connection.In HTTP 1.0 you had to open a new connection for each request/response pair. And after each response the connection would be closed. This lead to some big efficiency problems because of TCP Slow Start.OPTIONS method:HTTP/1.1 introduces the OPTIONS method. An HTTP client can use this method to determine the abilities of the HTTP server. It’s mostly used for Cross Origin Resource Sharing in web applications.Caching:HTTP 1.0 had support for caching via the header: If-Modified-Since.HTTP 1.1 expands on the caching support a lot by using something called ‘entity tag’. If 2 resources are the same, then they will have the same entity tags.HTTP 1.1 also adds the If-Unmodified-Since, If-Match, If-None-Match conditional headers.There are also further additions relating to caching like the Cache-Control header.100 Continue status:There is a new return code in HTTP/1.1 100 Continue. This is to prevent a client from sending a large request when that client is not even sure if the server can process the request, or is authorized to process the request. In this case the client sends only the headers, and the server will tell the client 100 Continue, go ahead with the body.HTTP 2.0 VS 1.1HTTP/2 is one of the largest changes to how the web works since HTTP v1.1 was released in June 1999. The new HTTP/2 protocol will make web pages load significantly faster, both on the desktop and mobile.The internet has changed dramatically since the HTTP 1.1 was launched back in 1999. Websites have become more dynamic, relying on frameworks (such as WordPress), Script Libraries (such as JavaScript) and a multitude of customized themes, images and other resources that need to be loaded for each web page. While developers have gotten creative in dealing with these limitations (Minification Combining scripts & CSS, Image Sprites, Lazy Loading, etc.), it wasn’t enough. The new Protocol has been designed to eliminate the need for many of these techniques and significantly speed up the response time of your website.What is HTTP/2?HTTP/2 is the next version of HTTP and is based on Google’s SPDY Protocol, which was implemented to speed up the loading of web pages. It is a new standard and is already starting to take over from the current protocol HTTP1.1 still used by the majority of websites.The primary benefits include the following:Multiplexing and concurrencyAs we have indicated, modern websites require the web browser to make a significant number of requests to render a web page. HTTP/1.0 allowed just one request to be made at a time, with HTTP/1.1 allowing multiple requests.Stream dependenciesWhen websites load the assets (HTML, CSS, JavaScript, images) that make up the web page the order in which they are loaded is important. You can’t have CSS (the styling) load at the end; otherwise, the web page may look deformed for the first few seconds. Secondly, you can’t have assets that require the jquery library (JavaScript) load before jquery as this can even break the functionality of some of the features on the website.With HTTP/1.1, this was easy, as head-of-line blocking made it simple to load various assets in the correct order. With HTTP/2, however, the response to the browser request may be received back in any order. The new protocol solves this by allowing the browser to communicate with the server and indicate the priorities for the respective objects files. No changes will be required by web app developers as modern web browsers will take care of prioritization and handling of data streams.Header compressionHTTP/2 has made significant improvements to the HTTP headers. Headers are used to inform the servers what information is needed, and the format in which that information can be delivered. One such header relates to compression, telling the servers that it supports GZIP. Another example relates to cookies that can be quite large in some cases.With HTTP/1.1 headers have to be provided for every asset requested, which if you have a page with over 100 requests can be time-consuming, and use bandwidth. The new Protocol can send all the headers in a single connection, also utilizing compression. Instead of 100 round trips required to load the headers for all the objects, it can now be done in a single trip.Server pushThe server can send resources the client has not yet requested. Applications designed to take advantage of the new server push capabilities in HTTP/2 must be carefully designed to balance performance and utility.This will be a substantial boost for people on high latency connections as it effectively could remove multiple round trips to the server.