You are on page 1of 3

HTTP is a communication protocol used to exchange of information b/w processes.

Its a stateless protocol main aim is to send & receive user information over a network. At applications level, it defines the kinds of requests clients request for & the responses provided by the servers to the clients. Working: The user makes a request for the specific URL. The Web browser establishes a .connection with the www.dcs.warwick.ac.uk server by locating its IP-address from a DNS server. The Web browser then sends a request to the server to retrieve the / dcs / index. Html file. The server responds with the information about the requested HTML page and the contents of the index. Html file. The process of sending the request & receiving the response is known as TRANSACTION. The HTTP session is only for the single transaction. Methods in HTTP: GET Retrieves the resource identified by the request URL HEAD - Returns the headers identified by the request URL POST - Sends large amount of complex data to the Web server PUT - Stores a resource under the request URL DELETE - Removes the resource identified by the request URL, from the server OPTIONS- Returns the HTTP methods that the server supports TRACE - Invokes a remote application layer associated with a request message GET Its used to access static resources such as HTML docs & images. Also retrieve dynamic information including parameter in URL Ex: GC_home_GC_feedback.asp? Dbname=GC_feedback where GC_feedback is a dynamic information & Dbname is a parameter. It contains a request URI, which is used, which is used to receive information from the request. Conditional GET-methods If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field, the GET method is changed to a conditional GET method. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method reduces unnecessary network usage by allowing cached entities to be refreshed. If the GET method associated with a request contains the range header field, the method is called a partial GET method. The partial GET method reduces unnecessary network usage by allowing partially-retrieved entities to be retrieved completely without transferring the data already. Held by the client. In this type of method, only a part of the entity is transferred; therefore, the name partial GET method. HEAD It is similar to GET method, but it provides only the Head & Meta information of the page. Its info is cacheable. POST Is commonly used for accessing dynamic resources or when a large amount of complex info is to be sent to the server. It provides the following functionalities: 1. Posting message to mailing list, newsgroup & bulletin board. 2. Providing a block of data, such as the result of submitting form, to a data-handling process. 3. Extending a database through an append operation. 4. Extending database through append operation. DELETE This method requests the web server to delete the resource identified by the Request URI.

OPTIONS This requests for info about the communication options available on the request / response chain identified by request URI. Its not cacheable. This method allows the client to determine the options and/ or requirements associated with a resource, or the capabilities of a server. TRACE This method is used to see the received I/p at the other end of the request chain. HTTP Response - When an HTTP request is received by a server, the status of the response is displayed with some Meta information about the response. This Meta information constitutes the part of the response header. The server also sends the content that corresponds to the resource specified in the request, except for the case of the HEAD request. The following code snippet provides the Meta information about the response: Response = status-L i ne '; *CC general-header | resonse-header; | entity-header ) CRLF [ message-body ] The response that is to be displayed to the user contains a status line. A status l1e is generally the first line of the Response header. The line contains information about the protocol versions and the status codes. The response header field allows the server to pass additional information of the response. These headers inform the server about further access to the resources requested by the Request-UR!. If a client sends a request to a URL, for example http://Java.sun.com/index.html,thebrowserreceives The content from the index.Html files as a part of the request. The content header fields of the response include Content-Type, Date, and Expires. Web applications with time-sensitive content may need to set such fields. For example, the Expires header field of a page can be set to the date specified in the Date header field to indicate the browsers that they should not cache the page. To indicate the type of content in request and response bodies, the response header fields use Multi Purpose Internet Mail Extensions (MIME). MIME types include text/html and image if content types. In this, the first part of the header indicates the type of data, such as text and image, while the second part indicates the standard extension, such as html for text and gif for image. MIMEis used to allow the exchange of different kinds of data files. At the beginning of each transmission, HTTP servers use MIME headers; and then the information in MIME headers is used by the browsers to decide how to parse and render the content. MIME header is also used by browsers while transmitting data in the request body and deciding the type of data being sent. For example, the default MIME type is application jx-www-form-urlencoded, which is used for encoding in POST requests.

PUT method requests that the enclosed entity be stored under the supplied URL. If the URL refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the origin server. If the URL does not point to an existing resource, and that URL is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URL. If the request passes through a cache and the URL identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method are not cacheable. The fundamental difference between POST and PUT requests is reflected in the different meaning of the request URL. The URL in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URL in a PUT request identifies the entity enclosed with the request -- the user agent knows what URL is intended and the server must not attempt to apply the request to some other resource. Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request should be applied to the resource created or modified by the PUT.

You might also like