| An HTTP request from a client to a server defines the HTTP method to be applied to a requested resource, the identifier of the resource, and the HTTP protocol version in use on the client. The request may include the MIME-like header fields that indicate the purpose of a request and provide additional information. The initial request line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by the space (SP) character, as follows: Request-Line = Method SP Request-URI SP HTTP-Version CRLF The resource upon which to apply the request is identified by a Request-URI (Uniform Resource Identifier). NOTE: As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings that identify via name, location, or any other characteristic a resource. A Uniform Resource Locator (URL) is a form of URI.
The most common form of Request-URI is that used to identify a resource on a Web server. In this case, the path of the URI is transmitted as the Request-URI in the initial line, and the network location of the URI is transmitted in a Host header field. For example, when a user types or clicks http://www.botsconsulting.com/about/default.htm in a browser, an HTTP/1.1 client will create a TCP connection to port 80 of the host www.botsconsulting.com and send the following at the beginning of the request: GET /about/default.htm HTTP/1.1 Host: www.botsconsulting.com NOTE: A Request-URI cannot be empty. If the path is not present in the original URL, it must be given as "/" (the server root).
HTTP Methods HTTP method names are case-sensitive. The methods defined in RFC 2616 are as follows: The OPTIONS method represents a request for information about the communication options available on the request-response chain identified by the Request-URI. This method 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 resource retrieval. The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data that will be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. The HEAD method is identical to GET except that the server must not return a message-body in the response. The meta information contained in the HTTP headers in response to a HEAD request should be identical to the information sent in response to a GET request. The POST method is used to request that the server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles Providing a block of data, such as the result of submitting a form, to a data-handling process Extending a database through an append operation.
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the server can create the resource with that URI. The DELETE method requests that the server delete the resource identified by the Request-URI. This method may be overridden by human intervention (or other means) on the server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. The TRACE method is used to invoke a remote, application-layer loopback 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. The CONNECT method name is reserved for use with a proxy that can dynamically switch to being a tunnel (e.g., SSL tunneling).
NOTE: The list of methods allowed by a resource can be specified in an Allow header field (see the General Header Fields section in this appendix). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server should return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server.
Request Header Fields The request header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation. The request header fields defined in RFC 2616 are as follows: The Accept header field can be used to specify certain media types that are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an inline image. The Accept-Charset header field can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server that is capable of representing documents in those character sets. The Accept-Encoding header field is similar to Accept, but restricts the content-codings that are acceptable in the response. The Accept-Language header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. The Authorization header field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. The Expect header field is used to indicate that particular server behaviors are required by the client. The From header field contains an Internet e-mail address for the human user who controls the requesting user agent, if given. This is not supported by most browsers. The Host header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally, an HTTP URL). The Host field value must represent the naming authority of the server or gateway given by the original URL. This allows the server or gateway to differentiate between internally ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address. The If-Match header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. The If-Modified-Since header field is used with a method to make it conditional: If the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not Modified) response will be returned without any message-body. The If-None-Match header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. The If-Range header field allows a client to "short-circuit" the second request. Informally, its meaning is "If the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity." If a client has a partial copy of an entity in its cache and wants to have an up-to-date copy of the entire entity in its cache, it could use the Range request header with a conditional GET (using either If-Unmodified-Since or If-Match, or both.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body. The If-Unmodified-Since header field is used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server should perform the requested operation as if the If-Unmodified-Since header were not present. The Max-Forwards header field provides a mechanism with the TRACE and OPTIONS methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain that appears to be failing or looping in midchain. The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. The Range header field allows the client to define the byte range specifications that apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body). A byte range operation may specify a single range of bytes or a set of ranges within a single entity. HTTP retrieval requests using conditional or unconditional GET methods may request one or more subranges of the entity instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request The Referer header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer," although the header field is misspelled). The Referer request header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, and so on. The TE header field indicates what extension transfer-codings the client is willing to accept in the response and whether it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters. The User-Agent header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents should include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts that form a significant part of the user agent.
|
