HTTP: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Subpagination Bot
m (Add {{subpages}} and remove any categories (details))
imported>Simon Koelsch
m (→‎All W3C status codes: added rfc title)
Line 37: Line 37:
</blockquote>
</blockquote>
====All W3C status codes====
====All W3C status codes====
All the codes are described [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1 here]. Note that this is only a ''recommandation''.
All the codes are described in [http://www.w3.org/Protocols/rfc2616/rfc2616.html RFC2616  Hypertext Transfer Protocol - HTTP/1.1] in [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1 Section 10]. Note that this is only a ''recommandation''.


===HTTP header and cache management===
===HTTP header and cache management===

Revision as of 14:41, 29 November 2007

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

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 classes

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.

All W3C status codes

All the codes are described in RFC2616 Hypertext Transfer Protocol - HTTP/1.1 in Section 10. Note that this is only a recommandation.

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