HTTP is a stateless request response based communication. The term stateless means it will not keep the history of past request response, that's why we are applying session over http request for getting an idea about past request. It is mainly used for the send data over the internet. The protocols communication usually takes place over TCP/IP, but any reliable transport can be used.
HTTP Protocol Versions
The first version of HTTP Protocol is HTTP/0.9, HTTP/1.0 came next, and now we normally use the HTTP/1.1 version. Below shows some comparison between HTTP/1.0 and HTTP/1.1
Host Header Field
HTTP 1.1 has a required Host header by specification. HTTP 1.0 does not officially require a Host header, but it doesn't hurt to add one, and many applications (proxies) expect to see the Host header regardless of the protocol version.
For Example:
GET / HTTP/1.1 Host: www.behindjava.com
This header is useful because it allows you to route a message through proxy servers, and also because your a web server can distinguish between different sites on the same server. So this means if you have behindjava.com and google.com both pointing to the same IP. Your web server can use the Host field to distinguish which site the client machine wants.
Persistent 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.
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. Also in HTTP 1.1 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 Messages and Message Format
In the case of HTTP Communication the Web browser is an HTTP client, and it sends a requests to server machines. From the browser if the user enters a url in the address bar or clicking on a hypertext link from the browser, the browser builds an HTTP request and sends it to the Internet Protocol address (IP address) indicated by the URL. The HTTP daemon in the destination server machine receives the request and sends back the requested file or files associated with the request.
If the HTTP Client get a connection to server according to requesting url the HTTP messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multi purpose Internet Mail Extensions (MIME) [RFC2045]. These messages are consisted of requests from client to server and responses from server to client . Lets find out the format of an http request as well as the HTTP response
HTTP Request Format
A generic HTTP Message format consist of mainly four items which are
A Start-line Zero or more header fields followed by CRLF An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields Optionally a message-body
Lets go with one-by-one
Message Start-Line
It become the first line of HTTP request. It contains the HTTP Request method being used for that particular request, the URI, and the HTTP protocol name with the version being used. It may look like 'GET /servlet/jspName.jsp HTTP/1.1' where the request method being used is 'GET' (We will discuss more about HTTP Methods later), the URI is '/servlet/fileName.jsp', and the protocol (with version) is 'HTTP/1.1'.
HTTP Request Headers Fields
It is used to communicate the information about client environment. The headers looks like any one of Content-Type, User-Agent, Accept-Encoding, Content-Length, Accept-Language, Host, etc.
HTTP Request Body
It consist of the actual request being sent to the HTTP Server. The HTTP Request Header and Body are separated by a blank line known as CRLF (CR means Carriage Return and LF means Line Feed).HTTP Response
Here follows the general format of an HTTP Response messageHTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache/2.2.14 (Win32) Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Vary: Authorization,Accept Accept-Ranges: bytes Content-Length: 88 Content-Type: text/html Connection: Closed <html> <body> <h1>Hello, World!</h1> </body> </html>
Message Start Line (Protocol/Version, Status Code, and its Description)
first line of a valid HTTP Response is consists of the protocol name, it's version, status code of the request, and a short description of the status code. A status code of 200 means the processing of request was successful and the description in this case will be 'OK'. Similarly, a status code of '404' means the file requested was not found at the HTTP Server at the expected location and the description in this case is 'File Not Found'. We will discuss more about HTTP request later
HTTP Responds Headers
The difference between HTTP Request and Responds header is HTTP Request Headers contain information about the environment of the client machine whereas HTTP Response Headers contain information about the environment of the server machine. HTTP Methods. Server, Content-Type, Last-Modified, Content-Length are the some of HTTP Responds Headers
HTTP Responds Body
It contains the actual response which is rendered in the client window (the browser window). The content of the body will be HTML code. Similar to HTTP Request, in this case also the Body and the Headers components are separated by a mandatory blank line (CRLF sequence)
HTTP Methods
The http url specifies where the server located. But the action that should be performed on the server become specified via HTTP Methods. Here below explains the http methods according to RFC 2616 specification
GET Method
The GET method is the simplest and the most frequently used request method. It is used to access the static resources, such as HTML documents and images. GET request can be used to retrieve dynamic information by including query parameters in the request URL. For instance, we can send a parameter name with the URL, such as http://www.behindjava.com?language=anish. In this example, Harsh is the dynamic information sent by including a parameter name in the request URL.
HEAD Method
This method doesnt have responds body. all other things are similar to GET Method. It is used when the client is requesting some information about a resource but not requesting the resource itself. This means that we have a faster way of checking the headers and some server info for a given resource on the server i.e. checking if a given url is serviceable, a given file exists, etc..Sometimes client might only need to view the header of a response (Content-Type or Content-Length).
POST Method
The Post method is commonly used for accessing dynamic resources or when a large amount of complex information is to be sent to the server. The POST request method provides the following functionalities:-
- Providing annotations of the existing resources.
- Posting a message to a bulletin board, newsgroup, mailing list, or a similar group of articles.
- Providing a block of data, such as the result of the submitting a form, to a data-handling process.
- Extending a database through an append operation.
PUT Method
The PUT method stores an entity in the specified Request-URI. The entity is a resource residing on the Web server under the specified Request-URI. If the Request-URI does not point to an existing resource, but is capable of being defined as a new resource by the requesting user, the Web Server can create the resource with that URI. If an existing resource is modified, either the 200(OK) or 204 (No Content) response code should be sent to indicate successful modification of a resource. The Web Server must inform the user via the 201 (Created) responses if a new resource is created.
DELETE Method
The DELETE method requests the Web server to delete the resource identified by the Request-URI. If the resulting response includes an parameter(entity) describing the status of deletion, the 200(OK) response code specifies that the resource has been deleted successfully. If the response is 202(Accepted), it specifies that the resource has not yet been deleted. Similarly, if the response code is 204 ( No Content), it specifies that the resource has been deleted but the response code does not include an entity.
OPTION Method
The OPTION method requests for information about the communication options available on the request/response chain identified by a Request-URI. Responses to this method are not cacheable. This method allows the client to determine the options and /or requirements associated with a resource, or the capabilities of a server. If the OPTIONS method includes an entity body, the media type must be indicated by the content-type field. the response should be a 200 OK and have an Allow header with a list of HTTP methods that may be used on this
200 OK Allow: HEAD,GET,PUT,DELETE,OPTIONS
TRACE Method
The TRACE method is used to invoke a remote application layer associated with a request message. The TRACE method is primarily used for debugging and testing purposes, and simply requests that the server echo back the request it received. This can be useful for identifying any changes to the request that is made by proxies. The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the request should reflect the message received back to the client as the entity-body of a 200 (OK) response.
TRACE requests can be disabled by making a change to the Apache server configuration. Unfortunately it is not possible to do this using the Limit directive since the processing for the TRACE request skips this authorisation checking. Instead the following lines can be added which make use of the mod_rewrite module.
RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]" - www.behindjava.com
No comments:
Post a Comment