- HTTP — Requests
- Request-Line
- Request Method
- Request-URI
- Request Header Fields
- Examples of Request Message
- Content-Type
- Syntax
- Directives
- Examples
- Content-Type in HTML forms
- Specifications
- Browser compatibility
- See also
- Found a content problem with this page?
- HTTP Request Methods
- HTTP Methods
- The GET Method
- The POST Method
- Compare GET vs. POST
- The PUT Method
- The HEAD Method
- The DELETE Method
- The PATCH Method
- The OPTIONS Method
- The CONNECT Method
- The TRACE Method
HTTP — Requests
An HTTP client sends an HTTP request to a server in the form of a request message which includes following format:
The following sections explain each of the entities used in an HTTP request message.
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 space SP characters.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Let’s discuss each of the parts mentioned in the Request-Line.
Request Method
The request method indicates the method to be performed on the resource identified by the given Request-URI. The method is case-sensitive and should always be mentioned in uppercase. The following table lists all the supported methods in HTTP/1.1.
The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
Same as GET, but it transfers the status line and the header section only.
Replaces all the current representations of the target resource with the uploaded content.
Removes all the current representations of the target resource given by URI.
Establishes a tunnel to the server identified by a given URI.
Describe the communication options for the target resource.
Performs a message loop back test along with the path to the target resource.
Request-URI
The Request-URI is a Uniform Resource Identifier and identifies the resource upon which to apply the request. Following are the most commonly used forms to specify an URI:
Request-URI = "*" | absoluteURI | abs_path | authority
S.N. | Method and Description |
---|---|
1 | The asterisk * is used when an HTTP 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. For example: |
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET /pub/WWW/TheProject.html HTTP/1.1
Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as «/» (the server root).
Request Header Fields
We will study General-header and Entity-header in a separate chapter when we will learn HTTP header fields. For now, let’s check what Request header fields are.
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.Here is a list of some important Request-header fields that can be used based on the requirement:
- 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
You can introduce your custom fields in case you are going to write your own custom Client and Web Server.
Examples of Request Message
Now let’s put it all together to form an HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com
GET /hello.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tutorialspoint.com Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: Keep-Alive
Here we are not sending any request data to the server because we are fetching a plain HTML page from the server. Connection is a general-header, and the rest of the headers are request headers. The following example shows how to send form data to the server using request message body:
POST /cgi-bin/process.cgi HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tutorialspoint.com Content-Type: application/x-www-form-urlencoded Content-Length: length Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: Keep-Alive licenseID=string&content=string&/paramsXML=string
Here the given URL /cgi-bin/process.cgi will be used to process the passed data and accordingly, a response will be returned. Here content-type tells the server that the passed data is a simple web form data and length will be the actual length of the data put in the message body. The following example shows how you can pass plain XML to your web server:
POST /cgi-bin/process.cgi HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.tutorialspoint.com Content-Type: text/xml; charset=utf-8 Content-Length: length Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: Keep-Alivestring
Content-Type
The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending).
In responses, a Content-Type header provides the client with the actual content type of the returned content. This header’s value may be ignored, for example when browsers perform MIME sniffing; set the X-Content-Type-Options header value to nosniff to prevent this behavior.
In requests, (such as POST or PUT ), the client tells the server what type of data is actually sent.
Header type | Representation header |
---|---|
Forbidden header name | no |
CORS-safelisted response header | yes |
CORS-safelisted request header | yes, with the additional restriction that values can’t contain a CORS-unsafe request header byte: 0x00-0x1F (except 0x09 (HT)), «():<>?@[\]<> , and 0x7F (DEL). It also needs to have a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded , multipart/form-data , or text/plain . |
Syntax
Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something
Directives
The MIME type of the resource or the data.
The character encoding standard. Case insensitive, lowercase is preferred.
For multipart entities the boundary directive is required. The directive consists of 1 to 70 characters from a set of characters (and not ending with white space) known to be very robust through email gateways. It is used to encapsulate the boundaries of the multiple parts of the message. Often, the header boundary is prepended with two dashes and the final boundary has two dashes appended at the end.
Examples
Content-Type in HTML forms
In a POST request, resulting from an HTML form submission, the Content-Type of the request is specified by the enctype attribute on the element.
form action="/" method="post" enctype="multipart/form-data"> input type="text" name="description" value="some text" /> input type="file" name="myFile" /> button type="submit">Submitbutton> form>
The request looks something like this (less interesting headers are omitted here):
POST /foo HTTP/1.1 Content-Length: 68137 Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="description" some text -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="myFile"; filename="foo.txt" Content-Type: text/plain (content of the uploaded file foo.txt) -----------------------------974767299852498929531610575--
Specifications
Browser compatibility
BCD tables only load in the browser
See also
Found a content problem with this page?
This page was last modified on Apr 10, 2023 by MDN contributors.
Your blueprint for a better internet.
HTTP Request Methods
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
Example: A client (browser) sends an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
HTTP Methods
The two most common HTTP methods are: GET and POST.
The GET Method
GET is used to request data from a specified resource.
Note that the query string (name/value pairs) is sent in the URL of a GET request:
Some notes on GET requests:
- GET requests can be cached
- GET requests remain in the browser history
- GET requests can be bookmarked
- GET requests should never be used when dealing with sensitive data
- GET requests have length restrictions
- GET requests are only used to request data (not modify)
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request:
POST /test/demo_form.php HTTP/1.1
Host: w3schools.com
Some notes on POST requests:
- POST requests are never cached
- POST requests do not remain in the browser history
- POST requests cannot be bookmarked
- POST requests have no restrictions on data length
Compare GET vs. POST
The following table compares the two HTTP methods: GET and POST.
GET | POST | |
---|---|---|
BACK button/Reload | Harmless | Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted) |
Bookmarked | Can be bookmarked | Cannot be bookmarked |
Cached | Can be cached | Not cached |
Encoding type | application/x-www-form-urlencoded | application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data |
History | Parameters remain in browser history | Parameters are not saved in browser history |
Restrictions on data length | Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters) | No restrictions |
Restrictions on data type | Only ASCII characters allowed | No restrictions. Binary data is also allowed |
Security | GET is less secure compared to POST because data sent is part of the URL |
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.
HEAD requests are useful for checking what a GET request will return before actually making a GET request — like before downloading a large file or response body.
The DELETE Method
The DELETE method deletes the specified resource.
The PATCH Method
The PATCH method is used to apply partial modifications to a resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
The CONNECT Method
The CONNECT method is used to start a two-way communications (a tunnel) with the requested resource.
The TRACE Method
The TRACE method is used to perform a message loop-back test that tests the path for the target resource (useful for debugging purposes).