### HTTP Request Example: GET with Host Header Source: https://www.rfc-editor.org/rfc/rfc2616.txt Shows a client request to an origin server using the absolute path form of Request-URI, with the network location in the Host header. The example uses a TCP connection to port 80 of www.w3.org. ```http GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org ``` -------------------------------- ### GET /pub/WWW/TheProject.html Source: https://www.rfc-editor.org/rfc/rfc2616.txt This snippet documents an HTTP GET request that retrieves a resource using the absolute path as described in the HTTP/1.1 specification. ```APIDOC ## GET /pub/WWW/TheProject.html ### Description Retrieves a resource from the origin server using the absolute path of the URI. The request must include a Host header field with the network location of the URI. ### Method GET ### Endpoint /pub/WWW/TheProject.html ### Parameters #### Path Parameters - **path** (string) - Required - The absolute path of the resource. If the original URI has no path, it MUST be given as "/". #### Header Parameters - **Host** (string) - Required - The network location of the URI (authority), e.g., "www.w3.org". ### Request Example ``` GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org ``` ### Response #### Success Response (200) The response contains the resource content. (Specific response details are not provided in the source.) ``` -------------------------------- ### GET Source: https://www.rfc-editor.org/rfc/rfc2616.txt The GET method retrieves a resource identified by the Request-URI. It is a safe method that should not have side effects. All general-purpose servers MUST support GET. ```APIDOC ## GET /path ### Description Retrieves the resource identified by the Request-URI. ### Method GET ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The resource identifier (e.g., absolute URI or absolute path). Example: `/pub/WWW/TheProject.html` or `http://www.w3.org/pub/WWW/TheProject.html`. ### Request Example ``` GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 ``` ### Response #### Success Response (200) - The response contains a representation of the resource. #### Response Example (No explicit example provided.) ``` -------------------------------- ### HEAD Source: https://www.rfc-editor.org/rfc/rfc2616.txt The HEAD method is identical to GET except that the server MUST NOT return a message body in the response. It is used to obtain metadata about a resource efficiently. ```APIDOC ## HEAD /path ### Description Identical to GET except that the server MUST NOT send a message body in the response. Used to obtain metadata about the resource. ### Method HEAD ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The resource identifier. ### Request Example ``` HEAD /pub/WWW/TheProject.html HTTP/1.1 ``` ### Response #### Success Response (200) - The response headers are identical to those for GET, but no message body is included. #### Response Example (No explicit example provided.) ``` -------------------------------- ### GET [Request-URI] Source: https://www.rfc-editor.org/rfc/rfc2616.txt The GET method retrieves a resource identified by the Request-URI. It supports conditional requests via If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range headersainer, and partial requests via the Range header. Responses may be cacheable per HTTP caching rules. ```APIDOC GET ### Description The GET method retrieves the information (entity) identified by the Request-URI. It can be a conditional GET when used with certain headers (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range) to transfer only under conditions, or a partial GET with a Range header to transfer only part of the entity. The response is cacheable if it meets HTTP caching requirements. ``` -------------------------------- ### HEAD [Request-URI] Source: https://www.rfc-editor.org/rfc/rfc2616.txt The HEAD method retrieves the same headers as GET but without a message-body. It is used to obtain metadata about a resource and can update cached entities. Responses may be cacheable. ```APIDOC HEAD ### Description The HEAD method is identical to GET except that the server must not return a message-body in the response. The response headers should be identical to those for a GET request. It is often used to obtain metainformation about an entity without transferring the entity-body. The response may be cacheable and used to update a cached entity. ``` -------------------------------- ### Range header in HTTP/1.1 Source: https://www.rfc-editor.org/rfc/rfc2616.txt HTTP retrieval requests using GET methods may request one or more sub-ranges 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. ```APIDOC ## [GET] Range header in HTTP/1.1 ### Description HTTP retrieval requests using GET methods may request one or more sub-ranges 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. ### Method GET ### Endpoint Any HTTP/1.1 GET request with a Range header ### Parameters #### Header Parameters - **Range** (string) - Required - Format: `Range = "Range" ":" ranges-specifier`. The byte ranges specification follows the grammar: `ranges-specifier = byte-ranges-specifier`, `byte-ranges-specifier = bytes-unit "=" byte-range-set`, where `byte-range-set` consists of one or more byte-range-spec or suffix-byte-range-spec. Example values: `bytes=0-499`, `bytes=500-999`, `bytes=-500`, `bytes=0-0,-1`. ### Response #### Success Response (206) If the specified ranges are satisfiable, the server SHOULD return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body. #### Success Response (416) If the byte-range-set is unsatisfiable, the server SHOULD return a response with a status of 416 (Requested range not satisfiable). ### Notes - The server MAY ignore the Range header. - HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and efficient partial retrieval of large entities. ``` -------------------------------- ### OPTIONS Source: https://www.rfc-editor.org/rfc/rfc2616.txt The OPTIONS method requests information about the communication options available for the resource identified by the Request-URI. It is used to query the capabilities of a server or resource without invoking an action. ```APIDOC ## OPTIONS * ### Description Retrieves the communication options available for the resource or server without initiating any resource retrieval. ### Method OPTIONS ### Endpoint * (asterisk) or Request-URI ### Parameters #### Request-URI - **Request-URI** (string) - Optional - The request URI can be an asterisk (*) to represent the server itself, or an absolute URI, absolute path, or authority. When using OPTIONS with an asterisk, the request applies to the server itself. ### Request Example ``` OPTIONS * HTTP/1.1 ``` ### Response #### Success Response (200) - The response includes an `Allow` header (see Section 14.7) indicating the methods supported by the resource. #### Response Example (No explicit example provided in the source.) ``` -------------------------------- ### CONNECT Source: https://www.rfc-editor.org/rfc/rfc2616.txt The CONNECT method requests the establishment of a tunnel to the destination origin server, typically used for secure connections through a proxy. ```APIDOC ## CONNECT /host:port ### Description Requests the establishment of a tunnel to the destination origin server, typically used for HTTPS through a proxy. ### Method CONNECT ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (string) - Required - The host and port number of the destination, e.g., `example.com:443`. ### Request Example ``` CONNECT example.com:443 HTTP/1.1 ``` ### Response #### Success Response (200) - A tunnel is established, and subsequent data is forwarded raw. #### Response Example (No explicit example provided.) ``` -------------------------------- ### OPTIONS [Request-URI] Source: https://www.rfc-editor.org/rfc/rfc2616.txt The OPTIONS method requests communication options available on the request/response chain. It includes the optional Max-Forwards header to target a specific proxy and specifies that responses without a body must include a Content-Length of 0. ```APIDOC OPTIONS ### Description 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 a resource retrieval. ### Method OPTIONS ### Endpoint [Request-URI] ### Parameters #### Request Headers - **Max-Forwards** (integer) - Optional - Limits the number of proxies the request can be forwarded through. If the value is zero, the proxy must not forward the request; if greater than zero, the proxy decrements the value when forwarding. ### Response #### Success Response (200) - **Content-Length** - Must be present if no response body is included, with value "0". #### Response Example (no response body example provided) ``` -------------------------------- ### POST [Request-URI] Source: https://www.rfc-editor.org/rfc/rfc2616.txt The POST method submits data to be processed by the server as a new subordinate of the Request-URI. It is used for annotation, posting, form submission, and database extension. If no URI is created, the response is 200 OK or 204 No Content. ```APIDOC POST ### Description The POST method requests that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI. It can be used for annotation, posting messages, providing data blocks, or extending a database. The action performed may not result in a URI-identifiable resource, in which case 200 (OK) or 204 (No Content) is the appropriate response. ``` -------------------------------- ### POST Source: https://www.rfc-editor.org/rfc/rfc2616.txt The POST method submits data to the specified resource, often causing a state change or side effect on the server. It is not a safe or idempotent method. ```APIDOC ## POST /path ### Description Submits data to the specified resource, often causing a state change or side effect on the server. ### Method POST ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The target resource. #### Body - **Content** (any) - Required - The data to be processed by the server. ### Request Example ``` POST /cgi-bin/process HTTP/1.1 ``` ### Response #### Success Response (200/201) - The response typically includes a representation of the result of the processing. #### Response Example (No explicit example provided.) ``` -------------------------------- ### TRACE Source: https://www.rfc-editor.org/rfc/rfc2616.txt The TRACE method is used to invoke a remote, application-layer loop-back of the request message. It allows the client to see what is being received at the other end. ```APIDOC ## TRACE /path ### Description Echoes back the received request so the client can see what intermediate servers are adding or changing in the request. ### Method TRACE ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The target resource. ### Request Example ``` TRACE /path HTTP/1.1 ``` ### Response #### Success Response (200) - The response contains the full request message as received by the server in the body. #### Response Example (No explicit example provided.) ``` -------------------------------- ### PUT Source: https://www.rfc-editor.org/rfc/rfc2616.txt The PUT method uploads a representation of the specified resource to the server. It is idempotent, meaning multiple identical requests should have the same effect as a single request. ```APIDOC ## PUT /path ### Description Uploads a representation of the specified resource to the server. ### Method PUT ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The target resource. #### Body - **Representation** (any) - Required - The new representation of the resource. ### Request Example ``` PUT /pub/WWW/TheProject.html HTTP/1.1 ``` ### Response #### Success Response (200/201/204) - The server stores the supplied entity under the given Request-URI. #### Response Example (No explicit example provided.) ``` -------------------------------- ### DELETE Source: https://www.rfc-editor.org/rfc/rfc2616.txt The DELETE method requests that the origin server delete the resource identified by the Request-URI. It is idempotent. ```APIDOC ## DELETE /path ### Description Deletes the specified resource. ### Method DELETE ### Endpoint [Request-URI] ### Parameters #### Request-URI - **Request-URI** (URI) - Required - The resource to delete. ### Request Example ``` DELETE /pub/WWW/TheProject.html HTTP/1.1 ``` ### Response #### Success Response (200/202/204) - The response indicates the success or failure of the deletion. #### Response Example (No explicit example provided.) ``` -------------------------------- ### Request Header Fields Grammar Source: https://www.rfc-editor.org/rfc/rfc2616.txt Defines the request-header production as a list of possible header fields, each with a reference to its section. This is part of the HTTP/1.1 grammar. ```abnf request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.