HTTP: Difference between revisions
imported>Jean Gebarowski |
imported>Jean Gebarowski |
||
Line 28: | Line 28: | ||
* 5xx (server error) : The server failed to fulfill an apparently valid request. | * 5xx (server error) : The server failed to fulfill an apparently valid request. | ||
For example, if the client requests a non-existent document, the status code will be "404 Not Found". | For example, if the client requests a non-existent document, the status code will be "404 Not Found". | ||
According to the [[W3C consortium]] : <blockquote> | |||
HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. | |||
</blockquote> | |||
===HTTP header and cache management=== | ===HTTP header and cache management=== |
Revision as of 06:46, 23 October 2007
HTTP (the Hypertext Transfer Protocol) is the network protocol on which the World Wide Web is based. Its original purpose was the transfer of HTML pages, but it is being used for transferring any type of document. It supports rich meta-information and has a robust caching system.
History
HTTP was created at CERN by Tim Berners-Lee in the 1980s as a way to share hypertext documents. After 1990, the protocol began to be used by other sites, primarily in the scientific world. Notable developments were the Mosaic web browser and the NCSA HTTPd web server, both developed at the National Center for Supercomputing Applications.
Technical details
The HTTP protocol follows a client-server model, where the client issues a request for a resource to the server. Requests and responses consist of several headers and, optionally, a body. Resources are identified using a URI (Uniform Resource Identifier).
Request methods
Clients can use one of eight request methods:
- HEAD
- GET
- POST
- PUT
- DELETE
- TRACE
- OPTIONS
- CONNECT
Typically, only GET, HEAD and POST methods are used in web applications, although protocols like WebDAV make use of others.
Status codes
Server responses include a status header, which informs the client whether the request succeeded. The status header is made up of a "status code" and a "reason phrase" (descriptive text). Status codes are grouped into classes:
- 1xx (informational) : Request received, continuing process
- 2xx (success) : The action was successfully received, understood, and accepted
- 3xx (redirect) : Further action must be taken in order to complete the request
- 4xx (client error) : The request contains bad syntax or cannot be fulfilled
- 5xx (server error) : The server failed to fulfill an apparently valid request.
For example, if the client requests a non-existent document, the status code will be "404 Not Found".
According to the W3C consortium :
HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached.
HTTP header and cache management
The HTTP message header includes a number of fields used to facilitate cache management. One of these, Etag (entity tag) is a string valued field that represents a value that should (weak entity tag) or must (strong entity tag) change whenever the page (or other resource) is modified. This allows browsers or other clients to determine whether or not the entire resource needs to be downloaded. The HEAD method, which returns the same message header that would be included in the response to a GET request, can be used to determine if a cached copy of the resource is up to date without actually downloading a new copy. Other elements of the message header can be used, for example, to indicate when a copy should expire (no longer be considered valid), or that it should not be cached at all. This can be useful, for example, when data is generated dynamically (for example, the number of visits to a web site).
External links
- RFC2616 - the formal specification of HTTP/1.1
- RFC2616 - section #6 - Status Code and Reason Phrase (HTTP/1.1)