Introduction to Internet

Programming
HTTP

HyperText Transfer Protocol (HTTP)

It is a networking protocol for distributed,
collaborative, hypermedia information systems.
HTTP is the foundation of data communication for the
World Wide Web
Its original purpose was to provide a way to publish
and retrieve HTML pages.
HTTP/1.1: Version of HTTP in common use today.

HTTP is an Application Layer protocol designed

within the framework of the Internet Protocol
Suite.

HyperText Transfer Protocol (HTTP)

HTTP is a request/response protocol between clients and
servers.
The originating client, such as a web browser, spider, or other
end-user tool, is referred to as the user agent.
The destination server, which stores or creates resources such
as HTML files and images, is called the origin server.
A response contains completion status information about the
request and may contain any content requested by the client in
its message body.

The HTTP protocol is designed to permit intermediate

network elements to improve or enable communications
between clients and servers.
High traffic website often benefit from web cache servers that
deliver content on behalf of the origin server to improve response
time.

HyperText Transfer Protocol (HTTP)

In between the user agent and origin server may
be several intermediaries, such as proxies,
gateways, and tunnels.
HTTP proxy servers at network boundaries facilitate
communication when clients without a globally
routable address are located in private networks by
relaying the requests and responses between clients
and servers

HTTP Session
An HTTP session is a sequence of network
request-response transactions.
An HTTP client initiates a request by
establishing a Transmission Control Protocol
(TCP) connection to a particular port on a remote
host (port 80 by default).
An HTTP server listening on that port waits for a
clients request message.

HTTP Session
Upon receiving the request, the server sends
back:
A status line, such as: HTTP/1.1 200 OK, and
A message of its own, the body of which is perhaps
the requested file, an error message or some other
information.

Resources to be accessed by HTTP are

identified using Uniform Resource Identifiers
(URIs) (or, more specifically, URLs) using the
http: or https: URI schemes.

HyperText Transfer Protocol (HTTP)

A typical HTTP message has a header and a
body:
Header:
Includes version, data from client/server, date, type of
content (MIME) and size.

Body:
Contains the actual resource/information.

HyperText Transfer Protocol (HTTP)

Typical MIME types:
htm/html, txt, jpg/jpeg, gif, png, xhtml, pdf, wmf, rm,
swf, zip, rar

According to the MIME type, the browser knows

how to handle the resource.
In-built support for some applications.
Helper applications (add-ins) for non-supported types.

HTTP Request Methods

HEAD: Asks for the response identical to the one that
would correspond to a GET request, but without the
response body.
Useful for retrieving meta-information written in response
headers, without having to transport the entire content.

GET: Requests a representation of the specified

resource.
By far the most common method used on the Web today.
Should not be used for operations that cause side-effects
(using it for actions in web applications is a common
misuse) see 'safe methods' later.

HTTP Request Methods

POST: Submits data to be processed (e.g. from
an HTML form) to the identified resource. The
data is included in the body of the request.
This may result in the creation of a new resource or
the updates of existing resources or both.

PUT: Uploads a representation of the specified

resource.
DELETE: Deletes the specified resource.

HTTP Request Methods

TRACE: Echoes back the received request, so
that a client can see what intermediate servers
are adding or changing in the request.
OPTIONS: Returns the HTTP methods that the
server supports.
CONNECT: Converts the request connection to a
transparent TCP/IP tunnel, usually to facilitate
SSL-encrypted communication (HTTPS) through
an unencrypted HTTP proxy.

Request Message
The request message consists of the following:
A request line, for example GET /images/logo.png
HTTP/1.1, which requests a resource called
/images/logo.png from the server.
Headers, such as Accept-Language: en
An empty line.
An optional message body.

Response message
The response message consists of the following:
A Status-Line (for example HTTP/1.1 200 OK, which
indicates that the client's request succeeded)
Headers, such as Content-Type: text/html
An empty line
An optional message body

HTTP Safe/Unsafe Methods

Some methods (e.g. HEAD or GET) are defined
as safe.
These are intended only for information retrieval and
should not change the state of the server (in other
words, they should not have side effects).

Unsafe methods (such as POST, PUT and

DELETE) change the state of the server.
They should be displayed to the user in a special way,
typically as buttons rather than links, thus making the
user aware of possible obligations (such as a button
that causes a financial transaction).

HTTP Safe/Unsafe Methods

Despite the required safety of GET requests, in
practice, they can cause changes on the server.
For example, a Web server may use the retrieval
through a simple hyperlink to initiate deletion of a
database record, thus causing a change of the server's
state as a side-effect of a GET request.
This is discouraged.

HTTP Persistent Connections

In HTTP/0.9 and 1.0, the connection is closed
after a single request/response pair.
In HTTP/1.1 a keep-alive-mechanism was
introduced, where a connection could be reused
for more than one request.
Such persistent connections reduce request latency
perceptibly, because the client does not need to renegotiate the TCP connection after the first request
has been sent.

HTTP Persistent Connections

Version 1.1 of the protocol also introduced:
Chunked transfer encoding to allow content on
persistent connections to be streamed, rather than
buffered.
HTTP pipelining, which allows clients to send some
types of requests before the previous response has
been received, further reducing lag.

HTTP Session State

HTTP is a stateless protocol.
The advantage of a stateless protocol is that
hosts do not need to retain information about
users between requests.
This forces programmers to use of alternative
methods for maintaining users' state; e.g.
When a host would like to customise content for a user
who has visited the site before.
When you want to edit/delete the current record in a
database.

HTTP Session State

The common methods for solving this problem
involve:
1.
2.
3.
4.

Sending and requesting cookies.

Server-side sessions.
Hidden variables (when current page is a form).
URL encoded parameters.
such as: .../index.php?userid=3.

Most web applications require the use of these

techniques.

Stateless Protocols
Advantages
Resource saving: It simplifies server design because it
does not need to dynamically allocate storage to deal
with conversations in progress or worry about freeing it
if a client dies in mid-transaction.

Disadvantages
It may be necessary to include more information in
each request and this extra information will need to be
interpreted by the server each time.
Most database applications require that the server
remembers their state.

Secure HTTP
Secure connections are used when sensitive
information needs to be exchanged.
e.g.: Credit Card nos.

They provide a method for authentication of the

connection and encryption of the information.
There are currently two methods of establishing a
secure HTTP connection:
1.The https URI Scheme.
2.The HTTP 1.1 Upgrade Header.

The https URI Scheme

This is syntactically identical to the http: scheme used
for normal HTTP connections.
It signals the browser to use an added encryption
layer: Secure Sockets Layer (SSL) or Transport Layer
Security (TLS) connection, to protect the traffic.
It uses port 443.
HTTPS connections are often used for payment
transactions on the World Wide Web and for sensitive
transactions in corporate information systems.

The https URI Scheme

Since browser support for the Upgrade Header is
nearly non-existent, the https URI Scheme is still
the dominant method of establishing a secure
HTTP connection.

The HTTP 1.1 Upgrade header

HTTP 1.1 introduced support for the Upgrade
header.
In the exchange, the client begins by making a
clear-text request, which is later upgraded to
TLS.
Either the client or the server may request (or
demand) that the connection be upgraded.