HTTP
Http protocol has been designed to serve and transfer information, resources across the world wide web with an architecture style (REST) which discourages bottleneck (by utilizing routers, gateways, proxys, tunneling etc), network congestion (by limiting no. of connection at a time, Connection timeout etc) and encourages Uptime and availability (using Stateless protocol, Connection close on Response),Scalability (using Stateless, Client-Server model, etc.), Uniformity (by defining a set of Methods like PUT, POST, GET, DELETE, HEAD, OPTION etc. for all and pre-defined purposes).
HTTP 1.0
Http 1.0 is the first and stable official specification of Http.
As per the Http 1.0,
HTTP 1.1
Http1.1 is the enhancement over Http1.0 which also addresses some of the major issues with Http 1.0.
Major issues with Http 1.0 are (the list is inclusive but not exhaustive):
The above issues have been addressed by the Http1.1 and it has modified the lower level protocol of HTTP. Nevertheless, it essentially satisfies the vision and high level requirement of HTTP as mentioned above.
With Http1.1,
The Http1.1 is backward compatible to Http1.0. This means the Http1.0 client can seamlessly work with Http1.1 Server. To accomplish this, the following rule applies with Http1.1 Server.
The Http Proxy coming between the end client and the server may need to deal with http version of Http Request as follows:
Http protocol has been designed to serve and transfer information, resources across the world wide web with an architecture style (REST) which discourages bottleneck (by utilizing routers, gateways, proxys, tunneling etc), network congestion (by limiting no. of connection at a time, Connection timeout etc) and encourages Uptime and availability (using Stateless protocol, Connection close on Response),Scalability (using Stateless, Client-Server model, etc.), Uniformity (by defining a set of Methods like PUT, POST, GET, DELETE, HEAD, OPTION etc. for all and pre-defined purposes).
- It states that a client should first establish a communication channel and send an Http request. Then each Http request for a resource or information must be acknowledged with an Http Response and then the communication channel should be disconnected from the server immediately.
- It also states that an established but idle channel should be time-out and disconnected automatically.
- It also recommends that an Http Client (for e.g. a browser) should make at most 2 connections per server at any given point of time.
- Http should not be used for a stateful, client server based model where dedicated and active connections are required for communication. It should not be used where both way communications can be initiated even through an established channel, but only for pull based Request/Response flow model.
HTTP 1.0
Http 1.0 is the first and stable official specification of Http.
As per the Http 1.0,
- Each pair of an Http1.0 Request (Client) and Http1.0 Response (Server) is carried and maintained by a single establish socket connection (Communication Channel) which is not shared by other Http1.0 Request or Http1.0 Response.
- An Http1.0 Request, send through the established socket connection, must be acknowledged with Http1.0 Response and closing the socket connection (communication channel) immediately. Http1.0 Response must follow only after the complete Http1.0 request has been received.
- An Http1.0 Server must sense the End of Http1.0 Request using “Content-Length” header field in case a entity (message) body is present with the request( say with POST and PUT) or with the receive of first bank line (CRLF and no more data) in case no entity body is present (say with GET, HEAD etc). Else a request should be ignored or acknowledged with an error response.
- An Http1.0 client should sense the end of Http1.0 Response either through the “Content-Length” header or when the Connection (communication channel) is closed.
- With limited connectivity between Http Client and Http Server, It assumes a synchronous model between Http Client and Http Server where the client waits for the response before processing further or sending next Http1.0 Request.
Http1.1 is the enhancement over Http1.0 which also addresses some of the major issues with Http 1.0.
Major issues with Http 1.0 are (the list is inclusive but not exhaustive):
- Each Http1.0 Request/Response has to be associated with a new Socket connection; an extra overhead, performance(latency) hit and unwanted bandwidth consumption is noticed.
- With large amount of entity body (as part of Http1.0 PUT/POST request or Http1.0 Response), it may not be received correctly by either end resulting into Http error status.
- Pre-determination of length of entity body (message) has to done before an Http1.0 PUT/POST request is sent.
- It assumes a Synchronous communication (inefficient time management) between client and server, where a client waits for the response before proceeding.
The above issues have been addressed by the Http1.1 and it has modified the lower level protocol of HTTP. Nevertheless, it essentially satisfies the vision and high level requirement of HTTP as mentioned above.
With Http1.1,
- It introduces “Persistent Connection”, a connection which is persisted (not disconnected) for being used by many Http1.1 Request/Response from the same Http1.1 client. A “Persistent Connection” is disconnected under the following scenarios:
- It is idle for long and time-out happens; Http1.1 Server disconnects it.
- Http1.1 Server decides to disconnect it for resource management purpose.
- When a “Connection:close” header is received in any of the Http1.1 response.
- When a “Connection:close” header is received in any of the Http1.1 request; Connection is closed after the corresponding Http1.1 response has been sent.
- The associated Client disconnects the connection.
- It introduces “Http Pipelining”, A Http1.1 Client can send or enqueue more than one Http1.1 request without waiting for the corresponding Http1.1 Responses. However, the Http1.1 server should dequeue or pick one Http1.1 request at a time, process it, send the Http1.1 response and then pick next Http request from the Persistent Connection. So, still the Http1.1 server processes only one Http Request at a time received from the same Communication Channel (Persistent Connection). This essentially ensures that the Http responses are sent in the same sequence in which the Http requests are received.
- It assumes Asynchronous Http1.1 client activity with “Persistent Connection” and “Http Pipelining” where an Http1.1 client can asynchronously pipeline the Http1.1 requests and handle the Http1.1 responses without waiting for each other.
- It introduces “Transfer-Encoding:chunked” header field in both Http1.1 Request and Response. This identifies an Entity Body to be sent in multiple “chunk” instead of the whole as complete body. Each “chunk” has a format of “[chunk-size] [chunk-extension] CRLF [chunk data] CRLF”. The last chunk of a chunked body should be of “0” length i.e. “0[chunk-extension]CRLF”. Using it, the Http1.1 Request/Response can send large size entity body in small chunks without fail and does not need to calculate the length of the whole entity body in advance.
- The Http1.1 Server should sense a End of Http1.1 Request using the following:
- If the Http1.1 Request does not allow a entity body (say for GET, HEAD), the first blank line(CRLF and no further data) shall be the end of request
- If “Transfer-Encoding:chunked” is included then the last chunk “0[chunk-extension]CRLF” followed by a optional “Trailer” and a Blank Line(CRLF) shall signals the end of the Entity Body and request.
- If “Content-Length” header is included, then it shall be uses to determine the length of Http Request. The presence of invalid value in the “Content-Length” should acknowledge with an Error Message.
- If “Transfer-Encoding:identity” is used then the “Content-Length” must be included else that Request/Response should be ignored and error message shall be shown.
- If both “Content-Length” and non identity transfer coding (“Transfer-Encoding:[chunked/compress etc.]”) is included then “Content-Length” should be ignored and the logic for “Transfer-Encoding” header field shall be used to determine the length of the Request.
- The Http1.1 Client should sense a End of Http1.1 Response using the following:
- If the Http1.1 Response does not allow a entity body (say for status code 3XX, 4XX etc.), the first blank line(CRLF and no further data) shall be the end of response
- If “Transfer-Encoding:chunked” is included then either on the (socket) connection close or the last chunk “0[chunk-extension]CRLF” followed by a optional “Trailer” and a Blank Line(CRLF) shall signals the end of the Entity Body and response.
- If “Content-Length” header is included, then it shall be uses to determine the length of Http Request. The presence of invalid value in the “Content-Length” should be reported to the end user.
- If “Transfer-Encoding:identity” is used then the “Content-Length” must be included else that Response should be ignored and error message should be shown.
- If both “Content-Length” and non identity transfer coding (“Transfer-Encoding:[chunked/compress etc.]”) is included then “Content-Length” should be ignored and the logic for “Transfer-Encoding” header field shall be used to determine the length of the Response.
The Http1.1 is backward compatible to Http1.0. This means the Http1.0 client can seamlessly work with Http1.1 Server. To accomplish this, the following rule applies with Http1.1 Server.
- The “Http/1.0” in the Request header shall imply the request is Http1.0 compliant request.
- Any Http1.0 request must be acknowledged with an Http1.0 Response and (socket) connection close immediately.
- The “connection:close” header should be included in the Http1.0 response.
The Http Proxy coming between the end client and the server may need to deal with http version of Http Request as follows:
- A proxy/gateway MUST NOT send a message with a version indicator which is greater than its actual version.
- The proxy/gateway’s response to a request MUST be in the same major version (i.e. “1”) and should be in the same Major.Minor (i.e. “1.0”) version as that of the request.
- A higher version proxy (say, Http1.1 Proxy) may upgrade the version (in the header) of lower HttpRequet version (say HTTP/1.0) to higher version (i.e. “HTTP/1.1”). It may also include the “Connection:close” in the header of such “1.0” compatible request.
- A lower version proxy (say,Http1.0 proxy) may ignore the request or downgrade the request version, responds with an error or switch to tunnel behavior if the request version is higher(say HTTP/1.1).
- http://www.w3.org/Protocols/rfc2616/rfc2616.html
- http://www.research.att.com/~bala/papers/h0vh1.html
No comments:
Post a Comment