Getting started with HTTP HTTP Status Codes HTTP requests HTTP responses Authentication Caching HTTP responses HTTP for APIs Cross Origin and Access Control Response encodings and compression

HTTP requests

Remarks:

The CONNECT method is reserved by the method definitions specification for use with proxies that are able to switch between proxying and tunneling modes (such as for SSL tunneling).

Sending a minimal HTTP request manually using Telnet

This example demonstrates that HTTP is a text-based Internet communications protocol, and shows a basic HTTP request and the corresponding HTTP response.

You can use Telnet to manually send a minimal HTTP request from the command line, as follows.

Start a Telnet session to the web server www.example.org on port 80:
```
telnet www.example.org 80
```
Telnet reports that you have connected to the server:
```
Connected to www.example.org.
Escape character is '^]'.
```

Enter a request line to send a GET request URL path /, using HTTP 1.1
```
GET / HTTP/1.1
```
Enter an HTTP header field line to identify the host name part of the required URL, which is required in HTTP 1.1
```
Host: www.example.org
```
Enter a blank line to complete the request.

The web server sends the HTTP response, which appears in the Telnet session.

The complete session, is as follows. The first line of the response is the HTTP status line, which includes the status code 200 and the status text OK, which indicate that the request was processed successfully. This is followed by a number of HTTP header fields, a blank line, and the HTML response.

$ telnet www.example.org 80
Trying 2606:2800:220:1:248:1893:25c8:1946...
Connected to www.example.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.example.org

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Thu, 21 Jul 2016 15:56:05 GMT
Etag: "359670651"
Expires: Thu, 28 Jul 2016 15:56:05 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (lga/1318)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
</head>
<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is established to be used for illustrative examples in documents. You may use this
    domain in examples without prior coordination or asking for permission.</p>
    <p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

(style element and blank lines removed from the HTML reponse, for brevity.)

Basic request format

In HTTP 1.1, a minimal HTTP request consists of a request line and a Host header:

GET /search HTTP/1.1 \r\n
Host: google.com \r\n
\r\n

The first line has this format:

Method Request-URI HTTP-Version CRLF

Method should be a valid HTTP method; one of ^[1][2]:

OPTIONS
GET
HEAD
POST
PUT
DELETE
PATCH
TRACE
CONNECT

Request-URI indicates either the URI or the path to the resource that the client is requesting. It can be either:

a fully-qualified URI, including scheme, host, (optional) port and path; or
a path, in which case the host must be specified in the Host header

HTTP-Version indicates the version of the HTTP protocol the client is using. For HTTP 1.1 requests this must always be HTTP/1.1.

The request line ends with a carriage return—line feed pair, usually represented by \r\n.

Request header fields

Header fields (usually just called ‘headers’) may be added to an HTTP request to provide additional information with the request. A header has semantics similar to parameters passed to a method in any programming language that supports such things.

A request with Host, User-Agent and Referer headers might look like this:

GET /search HTTP/1.1 \r\n
Host: google.com \r\n
User-Agent: Chrome/54.0.2803.1 \r\n
Referer: http://google.com/ \r\n
\r\n

A full list of supported HTTP 1.1 request headers can be found in the specification. The most common are:

Host - the host name part of the request URL (required in HTTP/1.1)
User-Agent - a string that represents the user agent requesting;
Referer - the URI that the client was referred here from; and
If-Modified-Since - gives a date that the server can use to determine if a resource has changed and indicate that the client can used a cached copy if it has not.

A header should be formed as Name: Value CRLF. Name is the header name, such as User-Agent. Value is the data assigned to it, and the line should end with a CRLF. Header names are case-insensitive and may only use letters, digits and the characters !#$%&'*+-.^_`|~ (RFC7230 section 3.2.6 Field value components).

The Referer header field name is a typo for ‘referrer’, introduced accidentally in RFC1945.

Message bodies

Some HTTP requests may contain a message body. This is additional data that the server will use to process the request. Message bodies are most often used in POST or PATCH and PUT requests, to provide new data that the server should apply to a resource.

Requests that include a message body should always include its length in bytes with Content-Length header.

A message body is included after all headers and a double CRLF. An example PUT request with a body might look like this:

PUT /files/129742 HTTP/1.1\r\n
Host: example.com\r\n
User-Agent: Chrome/54.0.2803.1\r\n
Content-Length: 202\r\n
\r\n
This is a message body. All content in this message body should be stored under the 
/files/129742 path, as specified by the PUT specification. The message body does
not have to be terminated with CRLF.

HEAD and TRACE requests must not include a message body.

Parameters:

HTTP Method	Purpose
`OPTIONS`	Retrieve information about the communication options (available methods and headers) available on the specified request URI.
`GET`	Retrieve the data identified by the request URI, or the data produced by the script available at the request URI.
`HEAD`	Identical to `GET` except that no message body will be returned by the server: only headers.
`POST`	Submit a block of data (specified in the message body) to the server for addition to the resouce specified in the request URI. Most commonly used for form processing.
`PUT`	Store the enclosed information (in the message body) as a new or updated resource under the given request URI.
`DELETE`	Delete, or queue for deletion, the resource identified by the request URI.
`TRACE`	Essentially an echo command: a functioning, compliant HTTP server must send the entire request back as the body of a 200 (OK) response.

Contributors

Topic Id: 2909

Example Ids: 5252,9847,9848,9849

This site is not affiliated with any of the contributors.