1.1-GET

The GET method is used to retrieve whatever information is identified by the Request-URL.
If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response.

The semantics of the GET method change to a "conditional GET" if the request message includes:

• If-Modified-Since header field
• If-Unmodified-Since header field
• If-Match header field
• If-None-Match header field
• Or If-Range header field

The semantics of the GET method change to a "partial GET" if the request message   includes a Range header field. A partial GET requests that only part of the entity be transferred.

1.2-HEAD
 
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.The metainformation contained  in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request.

1.3-POST

The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.

POST is designed to allow a uniform method to cover the following functions:

• 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.

1.4-PUT

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 origin 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 origin server can create the resource with that URI.

• If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response.
•  If an existing resource is modified,either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.
• If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem.
• The recipient of the entity MUST NOT ignore any Content-*(e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

1.5-DELETE

Th DELETE method requests that the origin server delete the resource identified by the Request-URI.

• the server SHOULD not indicate success unless, at the time the response is given, itintends to delete the resource or move it to an inaccessible location.
• A successful response SHOULD be 200 (OK) if the response includes an entity describing the status,202 (Accepted) if the action has not yet been enacted,or 204 (No Content) if the response is OK but does not include an entity.

1.6-TRACE

The TRACE method is used to invoke a remote, application-layer loop-back 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.

• TRACE allows the client to see what is being received at the otherend of the request chain and use that data for testing or diagnostic information.
• If successful, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http".

A request message from a client to a server have the following format:

Request = Method SP Request-URI SP HTTP-Version CRLF
                 *( general-header
                    | request-header
                    | entity-header )
                  CRLF
                 [ message-body ]

Method = "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE"

2.2-Request Header Fields

request-header = Accept
                         | Accept-Charset
                         | Accept-Encoding
                         | Accept-Language
                         | Authorization
                         | From
                         | Host
                         | If-Modified-Since
                         | If-Match
                         | If-None-Match
                         | If-Range
                         | If-Unmodified-Since
                         | Max-Forwards
                         | Proxy-Authorization
                         | Range
                         | Referer
                         | User-Agent

• GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
• GET /pub/WWW/TheProject.html HTTP/1.1

 Host: www.w3.org
 

3.1-Response Message Format

Response = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
                   *( general-header
                      | response-header
                      | entity-header )
                   CRLF
                   [ message-body ]

3.2-Status Code and Reason Phrase
 
 

Status Code	Reason Phrase
"100"	Continue
"101"	Switching Protocols
"200"	OK
"201"	Created
"202"	Accepted
"203"	Non-Authoritative Information
"204"	No Content
"205"	Reset Content
"206"	Partial Content
"300"	Multiple Choices
"301"	Moved Permanently
"302"	Moved Temporarily
"303"	See Other
"304"	Not Modified
"305"	Use Proxy
"400"	Bad Request
"401"	Unauthorized
"402"	Payment Required
"403"	Forbidden
"404"	Not Found
"405"	Method Not Allowed
"406"	Not Acceptable
"407"	Proxy Authentication Required
"408"	Request Time-out
"409"	Conflict
"410"	Gone
"411"	Length Required
"412"	Precondition Failed
"413"	Request Entity Too Large
"414"	Request-URI Too Large
"415"	Unsupported Media Type
"500"	Internal Server Error
"501"	Not Implemented
"502"	Bad Gateway
"503"	Service Unavailable
"504"	Gateway Time-out
"505"	HTTP Version not supported

• 1xx: Informational - Request received, continuing process
• 2xx: Success - The action was successfully received, understood, and accepted
• 3xx: Redirection - 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

3.3-Response Header Fields

response-header = Age
                            | Location
                            | Proxy-Authenticate
                            | Public
                            | Retry-After
                            | Server
                            | Vary
                            | Warning
                            | WWW-Authenticate

Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.

4.2-Entity Header Fields

Entity-header fields define optional metainformation about the entity-body or, if no body is present, about the resource identified by the request.

entity-header = Allow
                      | Content-Base
                      | Content-Encoding
                      | Content-Language
                      | Content-Length
                      | Content-Location
                      |Content-MD5
                      | Content-Range
                      | Content-Type
                      | ETag
                      | Expires
                      | Last-Modified

4.3-Entity Body

The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.

entity-body  =  *OCTET
 

5.1-Accept

The Accept request-header field can be used to specify certain media types which are acceptable for the response.

Accept = "Accept"  ":"  #( media-range [ accept-params ] )

media-range  =  (  "*/*"  |  ( type "/" "*" ) | ( type "/" subtype )  )  * ( ";" parameter )

accept-params  = " ;"  "q"  "="  qvalue

e.g:    Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity.

5.2-Accept-Charset

The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response.

Accept-Charset = "Accept-Charset" ":" 1#( charset [ ";" "q" "=" qvalue ] )
 
e.g:    Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

NOTES:

• The ISO-8859-1 character set can be assumed to be acceptable to all user agents.
• If no Accept-Charset header is present, the default is that any character set is acceptable.
• If an Accept-Charset header is present,and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD sendan error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.

5.3-Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource.

Accept-Ranges = "Accept-Ranges" ":" ( "bytes" | "none" )

e.g:    Accept-Ranges: bytes

NOTES:

• Clients MAY generate byte-range requests without having received this header for the resourc  involved.
• Servers that do not accept any kind of range request for a  resource MAY send accept-Ranges: none to advise the client not to attempt a range request.

5.4-Allow

The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI.

Allow  = "Allow" ":" 1#method

e.g:    Allow: GET, HEAD, PUT

NOTES:

• An Allow header field MUST be present in a 405 (Method   Not Allowed) response.
• The Allow header field MAY be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not required to support these methods and SHOULD include an Allow header in the response giving the actual supported methods.

5.5-Connection

The Connection general-header field allows the sender to specify options that are desired for that particular connection.

Connection-header = "Connection" ":" 1#(connection-token)
connection-token  = token

NOTES:

• HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, "Connection: close" in either the request or the response header fields indicates that the connection should not be considered `persistent'  after the current request/response is complete.
• HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

The Content-Base entity-header field may be used to specify the base URI for resolving relative URLs within the entity.

Content-Base = "Content-Base" ":" absoluteURI

5.7-Content-Encoding

The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field.

Content-Encoding  =  "Content-Encoding" ":" 1#content-coding

e.g:    Content-Encoding: gzip

NOTE:

• If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.

5.8-Content-Length

The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.

Content-Length    = "Content-Length" ":" 1*DIGIT

e.g:    Content-Length: 3495

5.9-Content-Range

The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should beinserted. It also indicates the total size of the full entity-body.
 
Content-Range = "Content-Range" ":" bytes-unit SP first-byte-pos "-" last-byte-pos "/" entity-length
entity-length           = 1*DIGIT

e.g: assuming that the entity contains a total of 1234 bytes:

• The first 500 bytes:                        Content-Range : bytes 0-499/1234
• The second 500 bytes:                   Content-Range : bytes 500-999/1234
• All except for the first 500 bytes:    Content-Range :  bytes 500-1233/1234
• The last 500 bytes:                         Content-Range :bytes 734-1233/1234

• The last-byte-pos value is less than first-byte-pos value,
• entity-length value is less than or equal to last-byte-pos value.

The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

Content-Type   = "Content-Type" ":" media-type

e.g:    Content-Type: text/html

5.11-Date

The Date general-header field represents the date and time at which the message was originated.

Date  = "Date" ":" HTTP-date

e.g:    Date: Tue, 15 Nov 1994 08:12:31 GMT

NOTES:

• origin servers MUST include a Date header field in all responses.
• Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional.

5.12- ETag

The ETag entity-header field defines the entity tag for the associated entity. The entity tag may be used for comparison with other entities from the same resource

ETag = "ETag" ":" entity-tag

e.g:    ETag: "xyzzy"
         ETag: W/"xyzzy"
         ETag: ""

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original

 Host = "Host" ":" host [ ":" port ]

e.g    :GET /pub/WWW/ HTTP/1.1
          Host: www.w3.org
A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL).

NOTE:

• The Host Header Field  allows the origin server to support multiple servers having single IP address which is referred to as "virtual hosting"

5.14-If-Modified-Since

The If-Modified-Since request-header field is used with the GET 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.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date

e.g:    If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

NOTES:

• If the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid.
• If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET.
• If the variant has not been modified since a valid If-Modified-Since date, the server MUST return a 304 (Not Modified) response.

5.15-If-Unmodified-Since

The If-Unmodified-Since request-header field is used with a method to make it conditional.

If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

e.g:    If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

NOTES:

• 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.
• If the requested variant has been modified since the specified time,the server MUST NOT perform the requested operation, and MUST return a 412 (Precondition Failed).
• If the specified date is invalid, the header is ignored.

The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.

Last-Modified  = "Last-Modified" ":" HTTP-date

e.g:    Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

NOTES:

• The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. For  files, it may be just the file system last-modified time.
• HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.

5.17-Public

The Public response-header field lists the set of methods supported by the server.

Public = "Public" ":" 1#method

Public: OPTIONS, MGET, MHEAD, GET, HEAD

5.18-Range Retrieval Requests

HTTP retrieval requests using conditional or unconditional GET methods may request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header.

Range = "Range" ":" bytes-unit "=" 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
suffix-byte-range-spec = "-" suffix-length
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
suffix-length  = 1*DIGIT

Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):

• The first 500 bytes (byte offsets 0-499, inclusive):                        bytes=0-499
• The second 500 bytes (byte offsets 500-999, inclusive):               bytes=500-999
• The first and last bytes only (bytes 0 and 9999):                           bytes=0-0,-1
• The final 500 bytes (byte offsets 9500-9999, inclusive):                bytes=-500
•  Or                                                                                              bytes=9500-

The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.

Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

e.g:    Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
         Retry-After: 120

In the latter example, the delay is 2 minutes.

5.20-Server

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens and comments identifying the server and any significant subproducts.

Server         = "Server" ":" 1*( product | comment )
 

5.21-Transfer-Encoding

The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This
differs from the Content-Encoding in that the transfer coding is a property of the message, not of the entity.

Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding

e.g:    Transfer-Encoding: chunked

5.22-User-Agent

The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes,User agents SHOULD include this field with requests.

User-Agent = "User-Agent" ":" 1*( product | comment )

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

6.2-URL

http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

host          = <A legal Internet host domain name
                      or IP address (in dotted-decimal form),
                      as defined by Section 2.1 of RFC 1123>

port          = *DIGIT

If the port is empty or not given, port 80 is assumed.

 6.3-Date/Time Formats

HTTP-date    = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date   = weekday "," SP date2 SP time SP "GMT"
asctime-date  = wkday SP date3 SP time SP 4DIGIT

date1             = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982)
date2             = 2DIGIT "-" month "-" 2DIGIT ; day-month-year (e.g., 02-Jun-82)
date3             = month SP ( 2DIGIT | ( SP 1DIGIT )); month day (e.g., Jun  2)

time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT; 00:00:00 - 23:59:59

wkday     = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday"

month      = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

Example:
Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

NOTE:

• The first format is preferred as an Internet standard.
• HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields.

6.4-Delta Seconds

Some HTTP header fields allow a time value to be specified as an integer number of seconds, represented in decimal, after the time that the message was received.

delta-seconds  = 1*DIGIT

6.5-Quality Values

qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )