HTTP PROTOCOL
SOLANKI HARDIK
I. INTRODUCTION
Designed in the early 1990s, HTTP is an extensible
protocol which has evolved over time. It is an application
layer protocol that is sent over TCP, or over a TLS-encrypted
TCP connection, though any reliable transport protocol could
theoretically be used. Due to its extensibility, it is used to
not only fetch hypertext documents, but also images and
videos or to post content to servers, like with HTML form
results. HTTP can also be used to fetch parts of documents
to update Web pages on demand. HTTP means HyperText
Transfer Protocol. HTTP is the underlying protocol used by
the World Wide Web and this protocol defines how messages
are formatted and transmitted, and what actions Web servers
and browsers should take in response to various commands.
HTTP is a protocol which allows the fetching of resources,
such as HTML documents. It is the foundation of any data
exchange on the Web and it is a client-server protocol, which
means requests are initiated by the recipient, usually the
Web browser. For example, when you enter a URL in your
browser, this actually sends an HTTP command to the Web
server directing it to fetch and transmit the requested Web
page. The other main standard that controls how the World
Wide Web works is HTML, which covers how Web pages
are formatted and displayed.
II. COMPONENTS OF HTTP BASED SYSTEMS
HTTP is a client-server protocol: requests are sent by one
entity, the user-agent (or a proxy on behalf of it). Most
of the time the user-agent is a Web browser, but it can
be anything, for example a robot that crawls the Web to
populate and maintain a search engine index. Each individual
request is sent to a server, which handles it and provides an
answer, called the response. Between the client and the server
there are numerous entities, collectively called proxies, which
perform different operations and act as gateways or caches,
for example.
HTTP is on top, at the application layer. Although impor-
tant to diagnose network problems, the underlying layers are
mostly irrelevant to the description of HTTP.
A. Client: the user-agent
Client: the user-agent The user-agent is any tool that acts
on the behalf of the user. This role is primarily performed by
the Web browser; other possibilities are programs used by
engineers and Web developers to debug their applications.
The browser is always the entity initiating the request. It
is never the server (though some mechanisms have been
HARSHIL MAHAVADIA BATCH-H4 ENROLL-180173107016,
added over the years to simulate server-initiated messages).
To present a Web page, the browser sends an original request
to fetch the HTML document that represents the page. It then
parses this file, making additional requests corresponding to
execution scripts, layout information (CSS) to display, and
sub-resources contained within the page (usually images and
videos). The Web browser then mixes these resources to
present to the user a complete document, the Web page.
Scripts executed by the browser can fetch more resources
in later phases and the browser updates the Web page
accordingly. A Web page is a hypertext document. This
means some parts of displayed text are links which can
be activated (usually by a click of the mouse) to fetch a
new Web page, allowing the user to direct their user-agent
and navigate through the Web. The browser translates these
directions in HTTP requests, and further interprets the HTTP
responses to present the user with a clear response.
B. The Web server
On the opposite side of the communication channel, is
the server, which serves the document as requested by the
client. A server appears as only a single machine virtually:
this is because it may actually be a collection of servers,
sharing the load (load balancing) or a complex piece of
software interrogating other computers (like cache, a DB
server, or e-commerce servers), totally or partially generating
the document on demand. A server is not necessarily a single
machine, but several server software instances can be hosted
on the same machine. With HTTP/1.1 and the Host header,
they may even share the same IP address.
C. Proxies
Between the Web browser and the server, numerous
computers and machines relay the HTTP messages. Due
to the layered structure of the Web stack, most of these
operate at the transport, network or physical levels, becoming
transparent at the HTTP layer and potentially making a
significant impact on performance. Those operating at the
application layers are generally called proxies. These can be
transparent, forwarding on the requests they receive without
altering them in any way, or non-transparent, in which case
they will change the request in some way before passing it
along to the server. Proxies may perform numerous functions:
1) caching (the cache can be public or private, like the
browser cache) 2) filtering (like an antivirus scan or parental
controls) 3) load balancing (to allow multiple servers to serve
the different requests) 4) authentication (to control access
to different resources) 5) logging (allowing the storage of
historical information)
 III. BASIC ASPECTS OF HTTP
HTTP is generally designed to be simple and human read-
able, even with the added complexity introduced in HTTP/2
by encapsulating HTTP messages into frames. HTTP mes-
sages can be read and understood by humans, providing
easier testing for developers, and reduced complexity for
newcomers.
A. HTTP is extensible
Introduced in HTTP/1.0, HTTP headers make this protocol
easy to extend and experiment with. New functionality can
even be introduced by a simple agreement between a client •
and a server about a new header’s semantics.
B. HTTP is stateless, but not sessionless
HTTP is called a stateless protocol because each command
is executed independently, without any knowledge of the
commands that came before it. This is the main reason that
it is difficult to implement Web sites that react intelligently
to user input. This shortcoming of HTTP is being addressed
in a number of new technologies, including ActiveX, Java, •
JavaScript and cookies. HTTP is stateless: there is no link
between two requests being successively carried out on the
same connection. This immediately has the prospect of being
problematic for users attempting to interact with certain
pages coherently, for example, using e-commerce shopping •
baskets. But while the core of HTTP itself is stateless, HTTP
cookies allow the use of stateful sessions. Using header
extensibility, HTTP Cookies are added to the workflow,
allowing session creation on each HTTP request to share
the same context, or the same state.
• Sessions Using HTTP cookies allows you to link requests
C. HTTP and connections
A connection is controlled at the transport layer, and
therefore fundamentally out of scope for HTTP. Though
HTTP doesn’t require the underlying transport protocol to
be connection-based; only requiring it to be reliable, or not
lose messages (so at minimum presenting an error). Among
the two most common transport protocols on the Internet,
TCP is reliable and UDP isn’t. HTTP therefore relies on the
TCP standard, which is connection-based. Before a client
and server can exchange an HTTP request/response pair, they
must establish a TCP connection, a process which requires
several round-trips. The default behavior of HTTP/1.0 is
to open a separate TCP connection for each HTTP re-
quest/response pair. This is less efficient than sharing a
single TCP connection when multiple requests are sent in
close succession. In order to mitigate this flaw, HTTP/1.1
introduced pipelining (which proved difficult to implement)
and persistent connections: the underlying TCP connection
can be partially controlled using the Connection header.
HTTP/2 went a step further by multiplexing messages over
a single connection, helping keep the connection warm and
more efficient. Experiments are in progress to design a better
transport protocol more suited to HTTP. For example, Google
is experimenting with QUIC which builds on UDP to provide
a more reliable and efficient transport protocol.
IV. W HAT CAN BE CONTROLLED BY HTTP
This extensible nature of HTTP has, over time, allowed
for more control and functionality of the Web. Cache or au-
thentication methods were functions handled early in HTTP
history. The ability to relax the origin constraint, by contrast,
has only been added in the 2010s. Here is a list of common
features controllable with HTTP.
• Caching How documents are cached can be controlled by
HTTP. The server can instruct proxies and clients, about
what to cache and for how long. The client can instruct
intermediate cache proxies to ignore the stored document.
Relaxing the origin constraint To prevent snooping and other
privacy invasions, Web browsers enforce strict separation
between Web sites. Only pages from the same origin can
access all the information of a Web page. Though such
constraint is a burden to the server, HTTP headers can relax
this strict separation on the server side, allowing a document
to become a patchwork of information sourced from different
domains; there could even be security-related reasons to do
so.
Authentication Some pages may be protected so that only
specific users can access them. Basic authentication may be
provided by HTTP, either using the WWW-Authenticate and
similar headers, or by setting a specific session using HTTP
cookies.
Proxy and tunneling Servers or clients are often located on
intranets and hide their true IP address from other computers.
HTTP requests then go through proxies to cross this network
barrier. Not all proxies are HTTP proxies. The SOCKS
protocol, for example, operates at a lower level. Other
protocols, like ftp, can be handled by these proxies.
with the state of the server. This creates sessions, despite
basic HTTP being a state-less protocol. This is useful not
only for e-commerce shopping baskets, but also for any site
allowing user configuration of the output.
V. HTTP F LOW
When a client wants to communicate with a server, either
the final server or an intermediate proxy, it performs the
following steps:
1. Open a TCP connection: The TCP connection is used to
send a request, or several, and receive an answer. The client
may open a new connection, reuse an existing connection,
or open several TCP connections to the servers.
2. Send an HTTP message: HTTP messages (before
HTTP/2) are human-readable. With HTTP/2, these simple
messages are encapsulated in frames, making them impossi-
ble to read directly, but the principle remains the same. For
example:
• GET / HTTP/1.1
• Host: developer.mozilla.org
• Accept-Language:fr
3.Read the response sent by the server, such as:
•HTTP/1.1 200 OK
•Date: Sat, 09 Oct 2010 14:28:02 GMT
•Server: Apache
•Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
•ETag: "51142bc1-7449-479b075b2891b"
• Accept-Ranges: bytes
• Content-Length: 29769
• Content-Type: text/html
4.Close or reuse the connection for further requests. If
HTTP pipelining is activated, several requests can be sent
without waiting for the first response to be fully received.
HTTP pipelining has proven difficult to implement in ex-
isting networks, where old pieces of software coexist with
modern versions. HTTP pipelining has been superseded in
HTTP/2 with more robust multiplexing requests within a
frame
VI. R EQUEST OR R ESPONSE
Req or response An HTTP client sends an HTTP request
to a server in the form of a request message which includes
following format:
1)A Request-line 2) Zero or more header (Gen-
eral|Request|Entity) fields followed by CRLF 3) An empty
line (i.e., a line with nothing preceding the CRLF) indicating
the end of the header fields 4)Optionally a message-body
Fig. 1. Sequence diagram
VII. R EQUEST-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 | abspath | authority
A. What is HTTP Response?
HTTP Response is the packet of information sent by
Server to the Client in response to an earlier Request made by
Client. HTTP Response contains the information requested
by the Client. For example, the request to Weather Web
Service made in the HTTP Request tutorial will contain
the weather details of the location. Just like HTTP Request,
HTTP Response also has the same structure:
• Status Line
• Headers, 0 or more Headers in the request
• An optional Body of the Request
Response Status Line A Status Line consists of three parts:
1. HTTP Protocol Version 2. Status Code 3. Reason Phrase
In the weather Rest Web Service example, lets scroll down
the page to see the Response section. In the response section
the first line is called the Status Line. As shown in the below
image:
It is clearly visible that the Status Line has ;following
information:
• HTTP Protocol Version as (HTTP/1.1)
• Status Code as 200
• Status Message as OK
B. Response Header
Just after the Status Line, Headers are displayed. Just like a
Request Header, Response Header also contains zero or more
Header lines. However, it is very uncommon to have zero
Headers in the response. Lines just after the Status Line and
before the Response Body are all Response Headers lines.
Headers are used to pass additional information to the Client.
See the image below:
In the response Header, there is a header named
Content-Type. The value of the header is application/json;
charset=utf-8. It means that server is informing the client
that the body of the response will contain a JSON formatted
data. If client needs to make any sense out of the response
body it should be interpret it as a JSON.
C. Response Body
Response Body contains the resource data that was re-
quested by the client.
VIII. HTTP MESSAGES
HTTP is based on the client-server architecture model
and a stateless request/response protocol that operates by
exchanging messages across a reliable TCP/IP connection.
An HTTP "client" is a program (Web browser or any other
client) that establishes a connection to a server for the
purpose of sending one or more HTTP request messages.
An HTTP "server" is a program ( generally a web server
like Apache Web Server or Internet Information Services
IIS, etc. ) that accepts connections in order to serve HTTP
requests by sending HTTP response messages. HTTP makes
use of the Uniform Resource Identifier (URI) to identify
a given resource and to establish a connection. Once the
connection is established, HTTP messages are passed in a
format similar to that used by the Internet mail [RFC5322]
and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045]. These messages include requests from client to
server and responses from server to client which will have
the following format:
HTTP-message = <Request> | <Response> ; HTTP/1.1
messages
HTTP requests and HTTP responses use a generic message
format of RFC 822 for transferring the required data. This
generic message format consists of the following four items.
• A Start-line
• Zero or more header fields followed by CRLF
• An empty line (i.e., a line with nothing preceding the
CRLF) • indicating the end of the header fields
• Optionally a message-body
In the following sections, we will explain each of the
entities used in an HTTP message. Message Start-Line
A start-line will have the following generic syntax: start-
line = Request-Line | Status-Line We will discuss Request-
Line and Status-Line while discussing HTTP Request and
HTTP Response messages respectively. For now, let’s see
the examples of start line in case of request and response:
GET /hello.htm HTTP/1.1 (This is Request-Line sent by the
client)
HTTP/1.1 200 OK (This is Status-Line sent by the server)
A. Message Header
HTTP header fields provide required information about
the request or response, or about the object sent in the
message body. There are four types of HTTP message
headers: • General-header: These header fields have general
applicability for both request and response messages. •
Request-header: These header fields have applicability only
for request messages. • Response-header: These header fields
have applicability only for response messages. • Entity-
header: These header fields define meta information about
the entity-body or, if no body is present, about the resource
identified by the request. All the above mentioned headers
follow the same generic format and each of the header field
consists of a name followed by a colon (:) and the field value
as follows: message-header = field-name ":" [ field-value ]
Following are the examples of various header fields:
User-Agent:curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l
zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
B. Message Body
The message body part is optional for an HTTP message
but if it is available, then it is used to carry the entity-body
associated with the request or response. If entity body is
associated, then usually Content-Type and Content-Length
headers lines specify the nature of the body associated. A
message body is the one which carries the actual HTTP
request data (including form data and uploaded, etc.) and
HTTP response data from the server ( including files, images,
etc.). Shown below is the simple content of a message body:
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
IX. S TATUS -L INE
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.
StatusLine = HTTPVersionSPStatus CodeSPReason-
PhraseCRLF
X. S TATUSCODE AND R EASONPHRASE
The Status-Code element is a 3-digit integer result code
of the attempt to understand and satisfy the request. These
codes are fully defined in section 10. The Reason-Phrase is
intended to give a short textual description of the Status-
Code. The Status-Code is intended for use by automata and
the Reason-Phrase is intended for the human user. The client
is not required to examine or display the Reason- Phrase. 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 pro-
cess
• 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
The individual values of the numeric status codes defined
for HTTP/1.1, and an example set of corresponding Reason-
Phrase’s, are presented below. The reason phrases listed here
are only recommendations – they MAY be replaced by local
equivalents without affecting the protocol.
HTTP status codes are extensible. HTTP applications are
not required to understand the mean- ing of all registered
status codes, though such understanding is obviously de-
sirable. However, applications MUST understand the class
of any status code, as indicated by the first digit, and
treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example,
if an unrecognized status code of 431 is received by the
client, it can safely assume that there was something wrong
with its request and treat the response as if it had received a
400 status code. In such cases, user agents SHOULD present
to the user the entity returned with the response, since that
entity is likely to include human- readable information which
will explain the unusual status.
XI. REFRENCES
https://www.webopedia.com/TERM/H/HTTP.html
https://www.tutorialspoint.com/http/http messages.htm
https://www.tutorialspoint.com/http/http requests.htm
https://developer.mozilla.org/en-
US/docs/Web/HTTP/Overview