HTTP Refresher Part II - Request and Response

In last article HTTP Refresher, I covered the basic of HTTP protocol. In this article, I am covering the HTTP request and HTTP Response. In this article we'll cover the Request/Status Line, Method, Request-URI, Request Header Fields, Status Code and Reason Phrase and Response Header Fields.
Request: A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
 
Request       = Request-Line              ;
                        *(( general-header        ;
                         | request-header         ;
                         | entity-header ) CRLF)  ;
                        CRLF
                        [ message-body ]          ;
  1. Request-Line: The 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 SP characters. No CR or LF is allowed except in the final CRLF sequence.
     
    Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
     
  2. Method: The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive. All general-purpose servers implements the methods GET and HEAD. All other methods are optional.
     
    Method         = "OPTIONS"               
                          | "GET"              
                          | "HEAD"             
                          | "POST"             
                          | "PUT"              
                          | "DELETE"           
                          | "TRACE"            
                          | "CONNECT"                
                          | extension-method
           extension-method = token
     
  3. Request-URI:The Request-URI is a Uniform Resource Identifier and identifies the resource upon which to apply the request.
     
    Request-URI    = "*" | absoluteURI | abs_path | authority 
     
    The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be
     
    OPTIONS * HTTP/1.1
     
    The absoluteURI form is required when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy may forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy must be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:
     
    GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
     
  4. The Resource Identified by a Request: The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field. An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:

    (a) If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.
    (b) If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value.
    (c) If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message.

  5. 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.
     
    request-header = Accept                   
                          | Accept-Charset           
                          | Accept-Encoding          
                          | Accept-Language          
                          | Authorization            
                          | Expect                   
                          | From                     
                          | Host                     
                          | If-Match
                          | If-Modified-Since        
                          | If-None-Match            
                          | If-Range                 
                          | If-Unmodified-Since      
                          | Max-Forwards             
                          | Proxy-Authorization      
                          | Range                    
                          | Referer                  
                          | TE                       
                          | User-Agent               
Response: After receiving and interpreting a request message, a server responds with an HTTP response message.
 
Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2
  1. Status-Line: The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
     
    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
     
  2. Status Code and Reason Phrase: The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

          - 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
    Following list contains common statuses:
    Status-Code    =
                "100"  ; Section 10.1.1: Continue
              | "101"  ; Section 10.1.2: Switching Protocols
              | "200"  ; Section 10.2.1: OK
              | "201"  ; Section 10.2.2: Created
              | "202"  ; Section 10.2.3: Accepted
              | "203"  ; Section 10.2.4: Non-Authoritative Information
              | "204"  ; Section 10.2.5: No Content
              | "205"  ; Section 10.2.6: Reset Content
              | "206"  ; Section 10.2.7: Partial Content
              | "300"  ; Section 10.3.1: Multiple Choices
              | "301"  ; Section 10.3.2: Moved Permanently
              | "302"  ; Section 10.3.3: Found
              | "303"  ; Section 10.3.4: See Other
              | "304"  ; Section 10.3.5: Not Modified
              | "305"  ; Section 10.3.6: Use Proxy
              | "307"  ; Section 10.3.8: Temporary Redirect
              | "400"  ; Section 10.4.1: Bad Request
              | "401"  ; Section 10.4.2: Unauthorized
              | "402"  ; Section 10.4.3: Payment Required
              | "403"  ; Section 10.4.4: Forbidden
              | "404"  ; Section 10.4.5: Not Found
              | "405"  ; Section 10.4.6: Method Not Allowed
              | "406"  ; Section 10.4.7: Not Acceptable
              | "407"  ; Section 10.4.8: Proxy Authentication Required
              | "408"  ; Section 10.4.9: Request Time-out
              | "409"  ; Section 10.4.10: Conflict
              | "410"  ; Section 10.4.11: Gone
              | "411"  ; Section 10.4.12: Length Required
              | "412"  ; Section 10.4.13: Precondition Failed
              | "413"  ; Section 10.4.14: Request Entity Too Large
              | "414"  ; Section 10.4.15: Request-URI Too Large
              | "415"  ; Section 10.4.16: Unsupported Media Type
              | "416"  ; Section 10.4.17: Requested range not satisfiable
              | "417"  ; Section 10.4.18: Expectation Failed
              | "500"  ; Section 10.5.1: Internal Server Error
              | "501"  ; Section 10.5.2: Not Implemented
              | "502"  ; Section 10.5.3: Bad Gateway
              | "503"  ; Section 10.5.4: Service Unavailable
              | "504"  ; Section 10.5.5: Gateway Time-out
              | "505"  ; Section 10.5.6: HTTP Version not supported
              | extension-code

          extension-code = 3DIGIT
          Reason-Phrase  = *<TEXT, excluding CR, LF>
  3. Response Header Fields: The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
     
    response-header = Accept-Ranges           ; Section 14.5
                           | Age                     ; Section 14.6
                           | ETag                    ; Section 14.19
                           | Location                ; Section 14.30
                           | Proxy-Authenticate      ; Section 14.33
                           | Retry-After             ; Section 14.37
                           | Server                  ; Section 14.38
                           | Vary                    ; Section 14.44
                           | WWW-Authenticate        ; Section 14.47
     
    Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response-header fields if all parties in the communication recognize them to be response-header fields. Unrecognized header fields are treated as entity-header fields.

Source: ietf.org
Your know, the comment floor is all yours, I would appreciate, if you use it.
- InstantKick Team