Behaviors

and Limitations of HTTP

Concepts:
HTTP is stateless protocol that relies on the immediate or nearly immediate processing of requests. Request are sent immediately and ideally they are processed without delay. However delay always happens. HTTP has a built-in mechanism to allow some flexibility with the time it takes to deliver requests timeouts. A timeout is the length of time a client waits for a request to be returned. Because of the immediate nature of HTTP, requests are not cached HTTP requests and responses are wholly independent. Web clients are not able to communicate to the web server if the packets get lost, there's no confirmation of delivery, there's no accounting to keep track of previous attempts to communicate and they are not privy to the contents of previous exchanges. Because HTTP is stateless, HTTP requests and responses do not retain any information passed if it does not go through.

HTTP Request
HTTP works by requests and responses A user makes a request by entering a website address and the browser returns the page. That single transaction may actually consist of many small requests and responses A response can also be an error message, perhaps indicating that the requested resource is not available or that the server is too busy to respond properly. HTTP is stateless that is, the Transmission protocol does not remember anything from one request to the next. Request can take a number of forms. GET HEAD POST PUT DELETE TRACE OPTIONS The GET Request The GET request attempts to return the resource represented in a URL In web programming, the GET request also ferries what is referred to as the query string, list of parameters attached to the URL after a question mark, represented in URL-encoded characters http://localhost:8080/requestdump?Question=what+is+JSP%3F http://localhost:8080/requestdump?Question=what+is+JSP%3F&Question=what+is+PHP%3 F

The HEAD Request The HEAD request is identical to GET except that the server is prohibited from sending a message-body in the response. You can use the HEAD request to obtain meta-information about the entity implied by the request without transferring the entire-body itself. You can also use the HEAD request to test hypertext links for validity, accessibility and recent modifications

The POST Request The POST request pushes a form body to a web server to do the following Post a message to a bulletin board, newsgroup, mailing list or similar group of articles Provide a block of data, such as the result of submitting a form, to a data-handling process The actual function performed by the POST request is determined by the server and usually depends an application linked to the Request-URI (Uniform Resource Identifier) The Request-URI is commonly known by the action parameter inside an HTML form tag. <form action=/jsp/c12.ImageLabeler method=post> the action indicates an object that can process the values packed inside the body of the POST The main difference between submitting a form using GET and POST is that GET shows form parameters appended to the query string, whereas POST passes from parameters along in the body of the request.

The PUT Request PUT was designed to place files on the web server PUT is not usually implemented directly You can control the uploading of files by using a POST form, which sends a file as MIME (Multipurpose Internet Mail Extension) encoding type multipart/form-data and with specialized code and application programming on the server side.

The DELETE Request DELETE was designed to remove files from the web server. Like PUT, most often it is not implemented directly because of security and administration concerns The TRACE Request The TRACE request is used in debugging to send back the request message It's primarily helpful for diagnosing forwarding problems when HTTP request must travel through a series of proxies The TRACE message is supposed to be sent back as the body of a 200 (OK) response and not simply thrown as an error TRACE has some useful features for debugging, namely the via header field and the maxforwards field.

The OPTION Request The OPTIONS requests asks for information about the communication options available on the request/response chain in identified by the Request-URI This request allows the client to determine the options and/or requirements associated with a resource or the capabilities of a server, without implying a resource action or initiating a resource retrieval The OPTIONS method was largely designed to be a server-to-server query-and-response mechanism