1305 lines
81 KiB
HTML
1305 lines
81 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
<title>In Introduction to HTTP Basics</title>
|
||
<link href="../css/programming_notes.css" rel="stylesheet" type="text/css" />
|
||
<link rel="shortcut icon" href="../favicon.ico" type="image/x-icon" /></head>
|
||
|
||
<body>
|
||
|
||
<!-- Begin the outermost container division -->
|
||
<div id="container">
|
||
|
||
<!-- print header -->
|
||
<script type="text/javascript" src="../scripts/header.js"></script>
|
||
|
||
<!-- begin main content division -->
|
||
<div id="content">
|
||
|
||
<h1>HTTP (HyperText Transfer Protocol)</h1>
|
||
<h2>Basics</h2>
|
||
|
||
<h3>Introduction</h3>
|
||
|
||
<h4>The WEB</h4>
|
||
<p>Internet (or The Web) is a massive distributed client/server information system as depicted in the following diagram.</p>
|
||
|
||
<img class="image-center" src="images/TheWeb.png" />
|
||
|
||
<p>Many applications are running concurrently over the Web, such as web browsing/surfing, e-mail, file transfer, audio & video streaming, and so on. In order for proper communication to take place between the client and the server, these applications must agree on a specific application-level protocol such as HTTP, FTP, SMTP, POP, and etc.</p>
|
||
|
||
<h4>HyperText Transfer Protocol (HTTP)</h4>
|
||
<p>HTTP (Hypertext Transfer Protocol) is perhaps the most popular application protocol used in the Internet (or The WEB).</p>
|
||
<ul>
|
||
<li>HTTP is an <em>asymmetric request-response client-server</em> protocol as illustrated. An HTTP client sends a request message to an HTTP server. The server, in turn, returns a response message. In other words, HTTP is a <em>pull protocol</em>, the client <em>pulls</em> information from the server (instead of server <em>pushes</em> information down to the client).
|
||
|
||
<img class="image-center" src="images/HTTP.png" />
|
||
</li>
|
||
|
||
<li>HTTP is a stateless protocol. In other words, the current request does not know what has been done in the previous requests.</li>
|
||
<li>HTTP permits negotiating of data type and representation, so as to allow systems to be built independently of the data being transferred.</li>
|
||
<li>Quoting from the RFC2616: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers."</li>
|
||
</ul>
|
||
|
||
<h4>Browser</h4>
|
||
|
||
<p>Whenever you issue a URL from your browser to get a web resource using HTTP, e.g. <code>http://www.nowhere123.com/index.html</code>, the browser turns the URL into a <em>request message</em> and sends it to the HTTP server. The HTTP server interprets the request message, and returns you an appropriate response message, which is either the resource you requested or an error message. This process is illustrated below:</p>
|
||
|
||
<img class="image-center" src="images/HTTP_Steps.png" />
|
||
|
||
<h4>Uniform Resource Locator (URL)</h4>
|
||
|
||
<p>A URL (Uniform Resource Locator) is used to uniquely identify a resource over the web. URL has the following syntax:</p>
|
||
|
||
<pre class="code-syntax"><em>protocol</em>://<em>hostname</em>:<em>port</em>/<em>path-and-file-name</em></pre>
|
||
|
||
<p>There are 4 parts in a URL:</p>
|
||
<ol>
|
||
<li><em>Protocol</em>: The application-level protocol used by the client and server, e.g., HTTP, FTP, and telnet.</li>
|
||
<li><em>Hostname</em>: The DNS domain name (e.g., <code>www.nowhere123.com</code>) or IP address (e.g., 192.128.1.2) of the server.</li>
|
||
<li><em>Port</em>: The TCP port number that the server is listening for incoming requests from the clients.</li>
|
||
<li><em>Path-and-file-name</em>: The name and location of the requested resource, under the server document base directory.</li>
|
||
</ol>
|
||
|
||
<p>For example, in the URL <code>http://www.nowhere123.com/docs/index.html</code>, the communication protocol is HTTP; the hostname is <code>www.nowhere123.com</code>. The port number was not specified in the URL, and takes on the default number, which is TCP port 80 for HTTP. The path and file name for the resource to be located is "<code>/docs/index.html</code>".</p>
|
||
|
||
<p>Other examples of URL are:</p>
|
||
<pre class="code-example">
|
||
ftp://www.ftp.org/docs/test.txt
|
||
mailto:user@test101.com
|
||
news:soc.culture.Singapore
|
||
telnet://www.nowhere123.com/</pre>
|
||
|
||
<h4>HTTP Protocol</h4>
|
||
<p>As mentioned, whenever you enter a URL in the address box of the browser, the browser translates the URL into a request message according to the specified protocol; and sends the request message to the server. </p>
|
||
<p>For example, the browser translated the URL <code>http://www.nowhere123.com/doc/index.html</code> into the following request message:</p>
|
||
|
||
<pre class="code-command"><strong>GET</strong> <strong>/docs/index.html</strong> HTTP/1.1
|
||
Host: <strong>www.nowhere123.com</strong>
|
||
Accept: image/gif, image/jpeg, */*
|
||
Accept-Language: en-us
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
(blank line)</pre>
|
||
|
||
<p>When this request message reaches the server, the server can take either one of these actions:</p>
|
||
<ol>
|
||
<li>The server interprets the request received, maps the request into a <em>file</em> under the server's document directory, and returns the file requested to the client.</li>
|
||
<li>The server interprets the request received, maps the request into a <em>program</em> kept in the server, executes the program, and returns the output of the program to the client.</li>
|
||
<li>The request cannot be satisfied, the server returns an error message.</li>
|
||
</ol>
|
||
|
||
<p>An example of the HTTP response message is as shown:</p>
|
||
|
||
<pre class="code-output"><strong>HTTP/1.1 200 OK</strong>
|
||
Date: Sun, 18 Oct 2009 08:56:53 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
|
||
ETag: "10000000565a5-2c-3e94b66c2e680"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 44
|
||
Connection: close
|
||
<strong>Content-Type: text/html</strong>
|
||
X-Pad: avoid browser bug
|
||
|
||
<strong><html><body><h1>It works!</h1></body></html></strong></pre>
|
||
|
||
<p>The browser receives the response message, interprets the message and displays the contents of the message on the browser's window according to the media type of the response (as in the Content-Type response header). Common media type include "<code>text/plain</code>", "<code>text/html</code>", "<code>image/gif</code>", "<code>image/jpeg</code>", "<code>audio/mpeg</code>", "<code>video/mpeg</code>", "<code>application/msword</code>", and "<code>application/pdf</code>".</p>
|
||
|
||
<p>In its idling state, an HTTP server does nothing but listening to the IP address(es) and port(s) specified in the configuration for incoming request. When a request arrives, the server analyzes the message header, applies rules specified in the configuration, and takes the appropriate action. The webmaster's main control over the action of web server is via the configuration, which will be dealt with in greater details in the later sections.</p>
|
||
|
||
<h4>HTTP over TCP/IP</h4>
|
||
<p>HTTP is a client-server application-level protocol. It typically runs over a TCP/IP connection, as illustrated. (HTTP needs not run on TCP/IP. It only presumes a reliable transport. Any transport protocols that provide such guarantees can be used.)</p>
|
||
|
||
<img class="image-center" src="images/HTTP_OverTCPIP.png" />
|
||
|
||
<p>TCP/IP (Transmission Control Protocol/Internet Protocol) is a set of transport and network-layer protocols for machines to communicate with each other over the network.</p>
|
||
<p>IP (Internet Protocol) is a network-layer protocol, deals with network addressing and routing. In an IP network, each machine is assigned an unique IP address (e.g., 165.1.2.3), and the IP software is responsible for routing a message from the source IP to the destination IP. In IPv4 (IP version 4), the IP address consists of 4 bytes, each ranges from 0 to 255, separated by dots, which is called a <em>quad-dotted form</em>. This numbering scheme supports up to 4G addresses on the network. The latest IPv6 (IP version 6) supports more addresses. Since memorizing number is difficult for most of the people, an english-like domain name, such as <code>www.nowhere123.com</code> is used instead. The DNS (Domain Name Service) translates the domain name into the IP address (via distributed lookup tables). A special IP address 127.0.0.1 always refers to your own machine. It's domian name is "<code>localhost</code>" and can be used for <em>local loopback testing</em>.</p>
|
||
<p>TCP (Transmission Control Protocol) is a transport-layer protocol, responsible for establish a connection between two machines. TCP consists of 2 protocols: TCP and UDP (User Datagram Package). TCP is <em>reliable</em>, each packet has a sequence number, and an acknowledgement is expected. A packet will be re-transmitted if it is not received by the receiver. Packet delivery is guaranteed in TCP. UDP does not guarantee packet delivery, and is therefore not reliable. However, UDP has less network overhead and can be used for applications such as video and audio streaming, where reliability is not critical.</p>
|
||
<p>TCP <em>multiplexes</em> applications within an IP machine. For each IP machine, TCP supports (multiplexes) up to 65536 ports (or sockets), from port number 0 to 65535. An application, such as HTTP or FTP, runs (or listens) at a particular port number for incoming requests. Port 0 to 1023 are pre-assigned to popular protocols, e.g., HTTP at 80, FTP at 21, Telnet at 23, SMTP at 25, NNTP at 119, and DNS at 53. Port 1024 and above are available to the users. </p>
|
||
<p>Although TCP port 80 is pre-assigned to HTTP, as the default HTTP port number, this does not prohibit you from running an HTTP server at other user-assigned port number (1024-65535) such as 8000, 8080, especially for test server. You could also run multiple HTTP servers in the same machine on different port numbers. When a client issues a URL without explicitly stating the port number, e.g., <code>http://www.nowhere123.com/docs/index.html</code>, the browser will connect to the default port number 80 of the host <code>www.nowhere123.com</code>. You need to explicitly specify the port number in the URL, e.g. <code>http://www.nowhere123.com:8000/docs/index.html</code> if the server is listening at port 8000 and not the default port 80.</p>
|
||
<p>In brief, to communicate over TCP/IP, you need to know (a) IP address or hostname, (b) Port number.</p>
|
||
<h4>HTTP Specifications</h4>
|
||
|
||
<p>The HTTP specification is maintained by <a href="http://www.w3.org">W3C (World-wide Web Consortium)</a> and available at <a href="http://www.w3.org/standards/techs/http">http://www.w3.org/standards/techs/http</a>. There are currently two versions of HTTP, namely, HTTP/1.0 and HTTP/1.1. The original version, HTTP/0.9 (1991), written by Tim Berners-Lee, is a simple protocol for transferring raw data across the Internet. HTTP/1.0 (1996) (defined in RFC 1945), improved the protocol by allowing MIME-like messages. HTTP/1.0 does not address the issues of proxies, caching, persistent connection, virtual hosts, and range download. These features were provided in HTTP/1.1 (1999) (defined in RFC 2616).</p>
|
||
|
||
<h3>Apache HTTP Server or Apache Tomcat Server</h3>
|
||
|
||
<p>A HTTP server (such as Apache HTTP Server or Apache Tomcat Server) is needed to study the HTTP protocol.</p>
|
||
<p>Apache HTTP server is a popular industrial-strength production server, produced by Apache Software Foundation (ASF) @ <a href="http://www.apache.org">www.apache.org</a>. ASF is an open-source software foundation. That is to say, Apache HTTP server is free, with source code.</p>
|
||
<p>The first HTTP server is written by Tim Berners Lee at CERN (European Center for Nuclear Research) at Geneva, Switzerland, who also invented HTML. Apache was built on NCSA (National Center for Supercomputing Applications, USA) "httpd 1.3" server, in early 1995. Apache probably gets its name from the fact that it consists of some original code (from an earlier NCSA httpd web server) plus some patches; or from the name of an American Indian tribe.</p>
|
||
<p>Read "<a href="https://www3.ntu.edu.sg/home/ehchua/programming/howto/Apache_HowToInstall.html">Apache How-to</a>" on how to install and configuare Apache HTTP server; or "<a href="https://www3.ntu.edu.sg/home/ehchua/programming/howto/Tomcat_HowTo.html">Tomcat How-to</a>" to install and get started with Apache Tomcat Server.</p>
|
||
<p> </p>
|
||
<h3>HTTP Request and Response Messages<a name="http_mesages"> </a></h3>
|
||
<p>HTTP client and server communicate by sending text messages. The client sends a <em>request message</em> to the server. The server, in turn, returns a <em>response message</em>.</p>
|
||
<p> An HTTP message consists of a <em>message header</em> and an optional <em>message body</em>, separated by a <em>blank line</em>, as illustrated below:</p>
|
||
<img class="image-center" src="images/HTTP_MessageFormat.png" />
|
||
|
||
<h4>HTTP Request Message</h4>
|
||
<p>The format of an HTTP request message is as follow:</p>
|
||
|
||
<img class="image-center" src="images/HTTP_RequestMessage.png" />
|
||
|
||
<h5>Request Line</h5>
|
||
|
||
<p>The first line of the header is called the <em>request line</em>, followed by optional <em>request headers</em>.</p>
|
||
<p> The request line has the following syntax:</p>
|
||
<pre class="code-syntax"><em>request-method-name</em> <em>request-URI</em> <em>HTTP-version</em></pre>
|
||
|
||
<ul>
|
||
<li><em>request-method-name</em>: HTTP protocol defines a set of request methods, e.g., GET, POST, HEAD, and OPTIONS. The client can use one of these methods to send a request to the server.</li>
|
||
<li><em>request-URI</em>: specifies the resource requested.</li>
|
||
<li><em>HTTP-version</em>: Two versions are currently in use: HTTP/1.0 and HTTP/1.1.</li>
|
||
</ul>
|
||
|
||
<p>Examples of request line are:</p>
|
||
<pre class="code-example">GET /test.html HTTP/1.1
|
||
HEAD /query.html HTTP/1.0
|
||
POST /index.html HTTP/1.1</pre>
|
||
|
||
<h5>Request Headers</h5>
|
||
|
||
<p>The request headers are in the form of <code>name:value</code> pairs. Multiple values, separated by commas, can be specified.</p>
|
||
|
||
<pre class="code-syntax"><em>request-header-name</em>: <em>request-header-value1</em>, <em>request-header-value2</em>, ...</pre>
|
||
|
||
<p>Examples of request headers are:</p>
|
||
|
||
<pre class="code-example">Host: www.xyz.com
|
||
Connection: Keep-Alive
|
||
Accept: image/gif, image/jpeg, */*
|
||
Accept-Language: us-en, fr, cn</pre>
|
||
|
||
<h5>Example</h5>
|
||
|
||
<p>The following shows a sample HTTP request message:</p>
|
||
<img class="image-center" src="images/HTTP_RequestMessageExample.png" />
|
||
|
||
<h4>HTTP Response Message</h4>
|
||
<p>The format of the HTTP response message is as follows:</p>
|
||
|
||
<img class="image-center" src="images/HTTP_ResponseMessage.png" />
|
||
|
||
<h5>Status Line</h5>
|
||
|
||
<p>The first line is called the <em>status line</em>, followed by optional response header(s).</p>
|
||
|
||
<p>The status line has the following syntax:</p>
|
||
<pre class="code-syntax"><em>HTTP-version</em> <em>status-code</em> <em>reason-phrase</em></pre>
|
||
|
||
<ul>
|
||
<li><em>HTTP-version</em>: The HTTP version used in this session. Either HTTP/1.0 and HTTP/1.1.</li>
|
||
<li><em>status-code</em>: a 3-digit number generated by the server to reflect the outcome of the request.</li>
|
||
<li> <em>reason-phrase</em>: gives a short explanation to the status code.</li>
|
||
<li> Common status code and reason phrase are "200 OK", "404 Not Found", "403 Forbidden", "500 Internal Server Error".</li>
|
||
</ul>
|
||
|
||
<p>Examples of status line are:</p>
|
||
<pre class="code-example">HTTP/1.1 200 OK
|
||
HTTP/1.0 404 Not Found
|
||
HTTP/1.1 403 Forbidden</pre>
|
||
|
||
<h5>Response Headers</h5>
|
||
|
||
<p>The response headers are in the form <code>name:value</code> pairs:</p>
|
||
<pre class="code-syntax"><em>response-header-name</em>: <em>response-header-value1</em>, <em>response-header-value2</em>, ...</pre>
|
||
|
||
<p>Examples of response headers are:</p>
|
||
<pre class="code-example">Content-Type: text/html
|
||
Content-Length: 35
|
||
Connection: Keep-Alive
|
||
Keep-Alive: timeout=15, max=100</pre>
|
||
|
||
<p>The response message body contains the resource data requested.</p>
|
||
|
||
<h5>Example</h5>
|
||
|
||
<p>The following shows a sample response message:</p>
|
||
|
||
<p><img class="image-center" src="images/HTTP_ResponseMessageExample.png" /></p>
|
||
|
||
<h3>HTTP Request Methods</h3>
|
||
|
||
<p>HTTP protocol defines a set of request methods. A client can use one of these request methods to send a request message to an HTTP server. The methods are:</p>
|
||
<ul>
|
||
<li>GET: A client can use the GET request to get a web resource from the server.</li>
|
||
<li>HEAD: A client can use the HEAD request to get the header that a GET request would have obtained. Since the header contains the last-modified date of the data, this can be used to check against the local cache copy.</li>
|
||
<li>POST: Used to post data up to the web server.</li>
|
||
<li>PUT: Ask the server to store the data.</li>
|
||
<li>DELETE: Ask the server to delete the data.</li>
|
||
<li>TRACE: Ask the server to return a diagnostic trace of the actions it takes.</li>
|
||
<li>OPTIONS: Ask the server to return the list of request methods it supports.</li>
|
||
<li>CONNECT: Used to tell a proxy to make a connection to another host and simply reply the content, without attempting to parse or cache it. This is often used to make SSL connection through the proxy.</li>
|
||
<li>Other extension methods.</li>
|
||
</ul>
|
||
|
||
<h3>"GET" Request Method</h3>
|
||
|
||
<p>GET is the most common HTTP request method. A client can use the GET request method to request (or "get") for a piece of resource from an HTTP server. A GET request message takes the following syntax:</p>
|
||
<pre class="code-syntax"><strong>GET</strong> <em>request</em>-<em>URI</em> <em>HTTP-version</em>
|
||
(<em>optional request headers</em>)
|
||
<span class="code-comment">(blank line)</span>
|
||
(<em>optional request body</em>)</pre>
|
||
|
||
<ul>
|
||
<li>The keyword GET is case sensitive and must be in uppercase.</li>
|
||
|
||
<li><em>request-URI</em>: specifies the path of resource requested, which must begin from the root "<code>/</code>" of the document base directory.</li>
|
||
|
||
<li><em>HTTP-version</em>: Either HTTP/1.0 or HTTP/1.1. This client <em>negotiates</em> the protocol to be used for the current session. For example, the client may request to use HTTP/1.1. If the server does not support HTTP/1.1, it may inform the client in the response to use HTTP/1.0.</li>
|
||
|
||
<li>The client uses the optional request headers (such as <code>Accept</code>, <code>Accept-Language</code>, and etc) to <em>negotiate</em> with the server and ask the server to deliver the preferred contents (e.g., in the language that the client preferred).</li>
|
||
<li>GET request message has an optional request body which contains the query string (to be explained later).</li>
|
||
</ul>
|
||
|
||
<h4>Testing HTTP Requests</h4>
|
||
|
||
<p>There are many way to test out the HTTP requests. Your can use utility program such as "<code>telnet</code>" or "<code>hyperterm</code>" (search for "<code>telnet.exe</code>" or "<code>hypertrm.exe</code>" under <code>c:\windows</code>), or write you own network program to send <em>raw</em> request message to an HTTP server to test out the various HTTP requests.</p>
|
||
|
||
<h5>Telnet</h5>
|
||
|
||
<p>"Telnet" is a very useful networking utility. You can use telnet to establish a TCP connection with a server; and issue raw HTTP requests. For example, suppose that you have started your HTTP server in the localhost (IP address 127.0.0.1) at port 8000:</p>
|
||
|
||
<pre class="code-example">> <strong>telnet
|
||
</strong>telnet> <strong>help</strong>
|
||
... <em>telnet help menu</em> ...
|
||
telnet> <strong>open 127.0.0.1 8000</strong>
|
||
Connecting To 127.0.0.1...
|
||
<strong>GET /index.html HTTP/1.0</strong>
|
||
(<em>Hit enter twice to send the terminating blank line</em> ...)
|
||
... <em>HTTP response message</em> ...</pre>
|
||
|
||
<p>Telnet is a character-based protocol. Each character you enter on the telnet client will be sent to the server immediately. Therefore, you cannot make typo error in entering you raw command, as delete and backspace will be sent to the server. You may have to enable "local echo" option to see the characters you enter. Check the telnet manual (search Windows' help) for details on using telnet.</p>
|
||
|
||
<h5>Network Program</h5>
|
||
|
||
<p>You could also write your own network program to issue raw HTTP request to an HTTP server. You network program shall first establish a TCP/IP connection with the server. Once the TCP connection is established, you can issue the raw request.</p>
|
||
|
||
<p>An example of network program written in Java is as shown (assuming that the HTTP server is running on the localhost (IP address 127.0.0.1) at port 8000):</p>
|
||
<pre class="code-example">import java.net.*;
|
||
import java.io.*;
|
||
|
||
public class <strong>HttpClient</strong> {
|
||
public static void main(String[] args) throws IOException {
|
||
<span class="code-comment">// The host and port to be connected.</span>
|
||
String host = "127.0.0.1";
|
||
int port = 8000;
|
||
<span class="code-comment">// Create a TCP socket and connect to the host:port.</span>
|
||
Socket socket = new Socket(host, port);
|
||
<span class="code-comment">// Create the input and output streams for the network socket.</span>
|
||
BufferedReader in
|
||
= new BufferedReader(
|
||
new InputStreamReader(socket.getInputStream()));
|
||
PrintWriter out
|
||
= new PrintWriter(socket.getOutputStream(), true);
|
||
<span class="code-comment">// Send request to the HTTP server.</span>
|
||
out.println("<strong>GET /index.html HTTP/1.0</strong>");
|
||
out.println(); <span class="code-comment">// blank line separating header & body</span>
|
||
out.flush();
|
||
<span class="code-comment">// Read the response and display on console.</span>
|
||
String line;
|
||
<span class="code-comment">// readLine() returns null if server close the network socket.</span>
|
||
while((line = in.readLine()) != null) {
|
||
System.out.println(line);
|
||
}
|
||
<span class="code-comment">// Close the I/O streams.</span>
|
||
in.close();
|
||
out.close();
|
||
}
|
||
}</pre>
|
||
|
||
<h4>HTTP/1.0 GET Request</strong></h4>
|
||
|
||
<p>The following shows the response of an HTTP/1.0 GET request (issue via telnet or your own network program - assuming that you have started your HTTP server):</p>
|
||
<pre class="code-command"><strong>GET /index.html HTTP/1.0</strong>
|
||
(enter twice to create a blank line)</pre>
|
||
|
||
<pre class="code-output"><strong>HTTP/1.1 200 OK</strong>
|
||
Date: Sun, 18 Oct 2009 08:56:53 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
|
||
ETag: "10000000565a5-2c-3e94b66c2e680"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 44
|
||
Connection: close
|
||
Content-Type: text/html
|
||
X-Pad: avoid browser bug
|
||
|
||
<html><body><h1>It works!</h1></body></html>
|
||
|
||
Connection to host lost.</pre>
|
||
|
||
<p>In this example, the client issues a GET request to ask for a document named "<code>/index.html</code>"; and negotiates to use HTTP/1.0 protocol. A blank line is needed after the request header. This request message does not contain a body.</p>
|
||
|
||
<p>The server receives the request message, interprets and maps the <em>request-URI</em> to a document under its document directory. If the requested document is available, the server returns the document with a response status code "200 OK". The response headers provide the necessary description of the document returned, such as the last-modified date (<code>Last-Modified</code>), the MIME type (<code>Content-Type</code>), and the length of the document (<code>Content-Length</code>). The response body contains the requested document. The browser will format and display the document according to its media type (e.g., Plain-text, HTML, JPEG, GIF, and etc.) and other information obtained from the response headers.</p>
|
||
|
||
<p>Notes:</p>
|
||
<ul>
|
||
<li>The request method name "GET" is case sensitive, and must be in uppercase.</li>
|
||
<li>If the request method name was incorrectly spelt, the server would return an error message "501 Method Not Implemented".</li>
|
||
<li>If the request method name is not allowed, the server will return an error message "405 Method Not Allowed". E.g., DELETE is a valid method name, but may not be allowed (or implemented) by the server.</li>
|
||
<li>If the <em>request-URI</em> does not exist, the server will return an error message "404 Not Found". You have to issue a proper <em>request-URI</em>, beginning from the document root "<code>/</code>". Otherwise, the server would return an error message "400 Bad Request".</li>
|
||
<li>If the <em>HTTP-version</em> is missing or incorrect, the server will return an error message "400 Bad Request".</li>
|
||
<li>In HTTP/1.0, by default, the server closes the TCP connection after the response is delivered. If you use telnet to connect to the server, the message "Connection to host lost" appears immediately after the response body is received. You could use an optional request header "<code>Connection: Keep-Alive</code>" to request for a persistent (or <code>keep-alive</code>) connection, so that another request can be sent through the same TCP connection to achieve better network efficiency. On the other hand, HTTP/1.1 uses keep-alive connection as default.</li>
|
||
</ul>
|
||
|
||
<h4>Response Status Code</h4>
|
||
<p>The first line of the response message (i.e., the status line) contains the response status code, which is generated by the server to indicate the outcome of the request.</p>
|
||
|
||
<p>The status code is a 3-digit number:</p>
|
||
<ul>
|
||
<li>1xx (Informational): Request received, server is continuing the process.</li>
|
||
<li>2xx (Success): The request was successfully received, understood, accepted and serviced.</li>
|
||
<li>3xx (Redirection): Further action must be taken in order to complete the request.</li>
|
||
<li>4xx (Client Error): The request contains bad syntax or cannot be understood.</li>
|
||
<li>5xx (Server Error): The server failed to fulfill an apparently valid request.</li>
|
||
</ul>
|
||
|
||
<p>Some commonly encountered status codes are:</p>
|
||
|
||
<ul>
|
||
<li>100 Continue: The server received the request and in the process of giving the response.</li>
|
||
<li>200 OK: The request is fulfilled.</li>
|
||
<li>301 Move Permanently: The resource requested for has been permanently moved to a new location. The URL of the new location is given in the response header called <code>Location</code>. The client should issue a new request to the new location. Application should update all references to this new location.</li>
|
||
<li>302 Found & Redirect (or Move Temporarily): Same as 301, but the new location is temporarily in nature. The client should issue a new request, but applications need not update the references.</li>
|
||
<li>304 Not Modified: In response to the <code>If-Modified-Since</code> conditional GET request, the server notifies that the resource requested has not been modified.</li>
|
||
<li>400 Bad Request: Server could not interpret or understand the request, probably syntax error in the request message.</li>
|
||
<li>401 Authentication Required: The requested resource is protected, and require client’s credential (username/password). The client should re-submit the request with his credential (username/password).</li>
|
||
<li>403 Forbidden: Server refuses to supply the resource, regardless of identity of client.</li>
|
||
<li>404 Not Found: The requested resource cannot be found in the server.</li>
|
||
<li>405 Method Not Allowed: The request method used, e.g., POST, PUT, DELETE, is a valid method. However, the server does not allow that method for the resource requested.</li>
|
||
<li>408 Request Timeout:</li>
|
||
<li>414 Request URI too Large:</li>
|
||
<li>500 Internal Server Error: Server is confused, often caused by an error in the server-side program responding to the request.</li>
|
||
<li>501 Method Not Implemented: The request method used is invalid (could be caused by a typing error, e.g., "GET" misspell as "Get").</li>
|
||
<li>502 Bad Gateway: Proxy or Gateway indicates that it receives a bad response from the upstream server.</li>
|
||
<li>503 Service Unavailable: Server cannot response due to overloading or maintenance. The client can try again later.</li>
|
||
<li>504 Gateway Timeout: Proxy or Gateway indicates that it receives a timeout from an upstream server.</li>
|
||
</ul>
|
||
|
||
<h4>More HTTP/1.0 GET Request Examples</h4>
|
||
|
||
<h5>Example: Misspelt Request Method</h5>
|
||
|
||
<p>In the request, "GET" is misspelled as "get". The server returns an error "501 Method Not Implemented". The response header "<code>Allow</code>" tells the client the methods allowed.</p>
|
||
<pre class="code-command"><strong>get</strong> /test.html HTTP/1.0
|
||
(enter twice to create a blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 <strong>501 Method Not Implemented</strong>
|
||
Date: Sun, 18 Oct 2009 10:32:05 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
<strong>Allow: GET,HEAD,POST,OPTIONS,TRACE</strong>
|
||
Content-Length: 215
|
||
Connection: close
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>501 Method Not Implemented</title>
|
||
</head><body>
|
||
<h1>Method Not Implemented</h1>
|
||
<p>get to /index.html not supported.<br />
|
||
</p>
|
||
</body></html></pre>
|
||
|
||
<h5>Example: 404 File Not Found</h5>
|
||
|
||
<p>In this GET request, the <em>request-URL</em> "<code>/t.html</code>" cannot be found under the server’s document directory. The server returns an error "404 Not Found".</p>
|
||
|
||
<pre class="code-command">GET <strong>/t.html</strong> HTTP/1.0
|
||
(enter twice to create a blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 <strong>404 Not Found</strong>
|
||
Date: Sun, 18 Oct 2009 10:36:20 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Content-Length: 204
|
||
Connection: close
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>404 Not Found</title>
|
||
</head><body>
|
||
<h1>Not Found</h1>
|
||
<p>The requested URL /t.html was not found on this server.</p>
|
||
</body></html></pre>
|
||
|
||
<h5>Example: Wrong HTTP Version Number</h5>
|
||
|
||
<p>In this GET request, the HTTP-version was misspelled, resulted in bad syntax. The server returns an error "400 Bad Request". HTTP-version should be either HTTP/1.0 or HTTP/1.1.</p>
|
||
|
||
<pre class="code-command">GET /index.html <strong>HTTTTTP/1.0</strong>
|
||
(enter twice to create a blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 <strong>400 Bad Request</strong>
|
||
Date: Sun, 08 Feb 2004 01:29:40 GMT
|
||
Server: Apache/1.3.29 (Win32)
|
||
Connection: close
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<HTML><HEAD>
|
||
<TITLE>400 Bad Request</TITLE>
|
||
</HEAD><BODY>
|
||
<H1>Bad Request</H1>
|
||
Your browser sent a request that this server could not understand.<P>
|
||
The request line contained invalid characters following the protocol string.<P><P>
|
||
</BODY></HTML></pre>
|
||
|
||
<p>Note: The latest Apache 2.2.14 ignores this error and returns the document with status code "200 OK".</p>
|
||
|
||
<h5>Example: Wrong Request-URI</h5>
|
||
|
||
<p>In the following GET request, the <em>request-URI</em> did not begin from the root "<code>/</code>", resulted in a "bad request".</p>
|
||
<pre class="code-command">GET test.html HTTP/1.0
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 <strong>400 Bad Request</strong>
|
||
Date: Sun, 18 Oct 2009 10:42:27 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Content-Length: 226
|
||
Connection: close
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>400 Bad Request</title>
|
||
</head><body>
|
||
<h1>Bad Request</h1>
|
||
<p>Your browser sent a request that this server could not understand.<br />
|
||
</p>
|
||
</body></html></pre>
|
||
|
||
<h5>Example: Keep-Alive Connection</h5>
|
||
|
||
<p>By fault, for HTTP/1.0 GET request, the server closes the TCP connection once the response is delivered. You could request for the TCP connection to be maintained, (so as to send another request using the same TCP connection, to improve on the network efficiency), via an optional request header "<code>Connection: Keep-Alive</code>". The server includes a "<code>Connection: Keep-Alive</code>" response header to inform the client that he can send another request using this connection, before the keep-alive <em>timeout</em>. Another response header "<code>Keep-Alive: timeout=x, max=x</code>" tells the client the timeout (in seconds) and the maximum number of requests that can be sent via this persistent connection.</p>
|
||
|
||
<pre class="code-command">GET /test.html HTTP/1.0
|
||
<strong>Connection: Keep-Alive</strong>
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 <strong>200 OK</strong>
|
||
Date: Sun, 18 Oct 2009 10:47:06 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
|
||
ETag: "10000000565a5-2c-3e94b66c2e680"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 44
|
||
<strong>Keep-Alive: timeout=5, max=100</strong>
|
||
<strong>Connection: Keep-Alive</strong>
|
||
Content-Type: text/html
|
||
|
||
<html><body><h1>It works!</h1></body></html></pre>
|
||
|
||
<p>Notes:</p>
|
||
<ul>
|
||
<li>The message "Connection to host lost" (for telnet) appears after "<code>keep-alive</code>" timeout</li>
|
||
<li>Before the "Connection to host lost" message appears (i.e., Keep-alive timeout), you can send another request through the same TCP connection.</li>
|
||
<li>The header "<code>Connection: Keep-alive</code>" is not case sensitive. The space is optional.</li>
|
||
<li>If an optional header is misspelled or invalid, it will be ignored by the server.</li>
|
||
</ul>
|
||
|
||
<h5>Example: Accessing a Protected Resource</h5>
|
||
|
||
<p>The following GET request tried to access a protected resource. The server returns an error "403 Forbidden". In this example, the directory "<code>htdocs\forbidden</code>" is configured to deny all access in the Apache HTTP server configuration file "<code>httpd.conf</code>" as follows:</p>
|
||
<pre class="code-example"><Directory "C:/apache/htdocs/forbidden">
|
||
Order deny,allow
|
||
deny from all
|
||
</Directory></pre>
|
||
|
||
<pre class="code-command">GET <strong>/forbidden/index.html</strong> HTTP/1.0
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 <strong>403 Forbidden</strong>
|
||
Date: Sun, 18 Oct 2009 11:58:41 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Content-Length: 222
|
||
Keep-Alive: timeout=5, max=100
|
||
Connection: Keep-Alive
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>403 Forbidden</title>
|
||
</head><body>
|
||
<h1>Forbidden</h1>
|
||
<p>You don't have permission to access /forbidden/index.html
|
||
on this server.</p>
|
||
</body></html></pre>
|
||
|
||
<h4>HTTP/1.1 GET Request</h4>
|
||
|
||
<p>HTTP/1.1 server supports so-called <em>virtual hosts</em>. That is, the same physical server could house several virtual hosts, with different hostnames (e.g., <code>www.nowhere123.com</code> and <code>www.test909.com</code>) and their own dedicated document root directories. Hence, in an HTTP/1.1 GET request, it is mandatory to include a request header called "<code>Host</code>", to select one of the virtual hosts.</p>
|
||
|
||
<h5>Example: HTTP/1.1 Request</h5>
|
||
|
||
<p>HTTP/1.1 maintains persistent (or keep-alive) connection by default to improve the network efficiency. You can use a request header "<code>Connection: Close</code>" to ask the server to close the TCP connection once the response is delivered.</p>
|
||
|
||
<pre class="code-command">GET /index.html HTTP/1.1
|
||
<strong>Host: 127.0.0.1</strong>
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Sun, 18 Oct 2009 12:10:12 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
|
||
ETag: "10000000565a5-2c-3e94b66c2e680"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 44
|
||
Content-Type: text/html
|
||
|
||
<html><body><h1>It works!</h1></body></html></pre>
|
||
|
||
<h5>Example: HTTP/1.1 Missing Host Header</h5>
|
||
|
||
<p>The following example shows that "<code>Host</code>" header is mandatory in an HTTP/1.1 request. If "<code>Host</code>" header is missing, the server returns an error "400 Bad Request".</p>
|
||
|
||
<pre class="code-command">GET /index.html HTTP/1.1
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 400 Bad Request
|
||
Date: Sun, 18 Oct 2009 12:13:46 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Content-Length: 226
|
||
Connection: close
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>400 Bad Request</title>
|
||
</head><body>
|
||
<h1>Bad Request</h1>
|
||
<p>Your browser sent a request that this server could not understand.<br />
|
||
</p>
|
||
</body></html></pre>
|
||
|
||
<h4>Conditional GET Requests</h4>
|
||
<p>In all the previous examples, the server returns the entire document if the request can be fulfilled (i.e. unconditional). You may use additional request header to issue a "conditional request". For example, to ask for the document based on the last-modified date (so as to decide whether to use the local cache copy), or to ask for a portion of the document (or range) instead of the entire document (useful for downloading large documents).</p>
|
||
|
||
<p>The conditional request headers include:</p>
|
||
<ul>
|
||
<li><code>If-Modified-Since</code> (check for response status code "304 Not Modified").</li>
|
||
<li><code>If-Unmodified-Since</code></li>
|
||
<li><code>If-Match</code></li>
|
||
<li><code>If-None-Match</code></li>
|
||
<li><code>If-Range</code></li>
|
||
</ul>
|
||
|
||
<h4>Request Headers</h4>
|
||
|
||
<p>This section describes some of the commonly-used request headers. Refer to HTTP Specification for more details. The syntax of header name is words with initial-cap joined using dash (<code>-</code>), e.g., <code>Content-Length</code>, <code>If-Modified-Since</code>.</p>
|
||
|
||
<p><code><strong>Host: <em>domain-name</em></strong></code> - HTTP/1.1 supports virtual hosts. Multiple DNS names (e.g., www.nowhere123.com and www.nowhere456.com) can reside on the same physical server, with their own document root directories. <code>Host</code> header is mandatory in HTTP/1.1 to select one of the hosts.</p>
|
||
|
||
<p>The following headers can be used for <em>content negotiation</em> by the client to ask the server to deliver the preferred type of the document (in terms of the media type, e.g. JPEG vs. GIF, or language used e.g. English vs. French) if the server maintain multiple versions for the same document.</p>
|
||
|
||
<p><strong><code>Accept: <em>mime-type-1</em>, <em>mime-type-2</em>, ...</code></strong> - The client can use the <code>Accept</code> header to tell the server the MIME types it can handle and it prefers. If the server has multiple versions of the document requested (e.g., an image in GIF and PNG, or a document in TXT and PDF), it can check this header to decide which version to deliver to the client. (E.g., PNG is more advanced more GIF, but not all browser supports PNG.) This process is called <em>content-type negotiation</em>.</p>
|
||
|
||
<p><strong><code>Accept-Language: <em>language-1</em>, <em>language-2</em>, ...</code></strong> - The client can use the <code>Accept-Language</code> header to tell the server what languages it can handle or it prefers. If the server has multiple versions of the requested document (e.g., in English, Chinese, French), it can check this header to decide which version to return. This process is called <em>language negotiation</em>.</p>
|
||
|
||
<p><strong><code>Accept-Charset: <em>Charset-1</em>, <em>Charset-2</em>, ...</code></strong> - For character set negotiation, the client can use this header to tell the server which character sets it can handle or it prefers. Examples of character sets are ISO-8859-1, ISO-8859-2, ISO-8859-5, BIG5, UCS2, UCS4, UTF8.</p>
|
||
|
||
<p><strong><code>Accept-Encoding: <em>encoding-method-1</em>, <em>encoding-method-2</em>, ...</code></strong> - The client can use this header to tell the server the type of encoding it supports. If the server has encoded (or compressed) version of the document requested, it can return an encoded version supported by the client. The server can also choose to encode the document before returning to the client to reduce the transmission time. The server must set the response header "<code>Content-Encoding</code>" to inform the client that the returned document is encoded. The common encoding methods are "<code>x-gzip</code> (<code>.gz</code>, <code>.tgz</code>)" and "<code>x-compress</code> (<code>.Z</code>)".</p>
|
||
|
||
<p><strong><code>Connection: Close|Keep-Alive</code></strong> - The client can use this header to tell the server whether to close the connection after this request, or to keep the connection alive for another request. HTTP/1.1 uses persistent (keep-alive) connection by default. HTTP/1.0 closes the connection by default.</p>
|
||
|
||
<p><strong><code>Referer: <em>referer-URL</em></code></strong> - The client can use this header to indicate the referrer of this request. If you click a link from web page 1 to visit web page 2, web page 1 is the referrer for request to web page 2. All major browsers set this header, which can be used to track where the request comes from (for web advertising, or content customization). Nonetheless, this header is not reliable and can be easily spoofed. Note that Referrer is misspelled as "Referer" (unfortunately, you have to follow too).</p>
|
||
|
||
<p><strong><code>User-Agent: <em>browser-type</em></code></strong> - Identify the type of browser used to make the request. Server can use this information to return different document depending on the type of browsers.</p>
|
||
|
||
<p><strong><code>Content-Length: <em>number-of-bytes</em></code></strong> - Used by POST request, to inform the server the length of the request body.</p>
|
||
|
||
<p><strong><code>Content-Type: <em>mime-type</em></code></strong> - Used by POST request, to inform the server the media type of the request body.</p>
|
||
|
||
<p><strong><code>Cache-Control: no-cache|...</code></strong> - The client can use this header to specify how the pages are to be cached by proxy server. "<code>no-cache</code>" requires proxy to obtain a fresh copy from the original server, even though a local cached copy is available.
|
||
(HTTP/1.0 server does not recognize "<code>Cache-Control: no-cache</code>". Instead, it uses "<code>Pragma: no-cache</code>". Included both request headers if you are not sure about the server’s version.)</p>
|
||
|
||
<p><strong><code>Authorization</code></strong>: Used by the client to supply its credential (username/password) to access protected resources. (This header will be described in later chapter on authentication.)</p>
|
||
|
||
<p><strong><code>Cookie: <em>cookie-name-1</em>=<em>cookie-value-1</em>, <em>cookie-name-2</em>=<em>cookie-value-2</em>, ...</code></strong> - The client uses this header to return the cookie(s) back to the server, which was set by this server earlier for state management. (This header will be discussed in later chapter on state management.)</p>
|
||
|
||
<p><strong><code>If-Modified-Since: <em>date</em></code></strong> - Tell the server to send the page only if it has been modified after the specific date.</p>
|
||
|
||
<h4>GET Request for Directory</h4>
|
||
|
||
<p>Suppose that a directory called "<code>testdir</code>" is present in the document base directory "<code>htdocs</code>".</p>
|
||
|
||
<p>If a client issues a GET request to "<code>/testdir/</code>" (i.e., at the directory).</p>
|
||
|
||
<ol>
|
||
<li>The server will return "<code>/testdir/index.html</code>" if the directory contains a "<code>index.html</code>" file.</li>
|
||
<li>Otherwise, the server returns the directory listing, if directory listing is enabled in the server configuration.</li>
|
||
<li>Otherwise, the server returns "404 Page Not Found".</li>
|
||
</ol>
|
||
|
||
<p>It is interesting to take note that if a client issue a GET request to "<code>/testdir</code>" (without specifying the directory path <code>"/</code>"), the server returns a "301 Move Permanently" with a new "<code>Location</code>" of "<code>/testdir/</code>", as follows.</p>
|
||
|
||
<pre class="code-command">GET /testdir HTTP/1.1
|
||
Host: 127.0.0.1
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 <strong>301 Moved Permanently</strong>
|
||
Date: Sun, 18 Oct 2009 13:19:15 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
<strong>Location: http://127.0.0.1:8000/testdir/</strong>
|
||
Content-Length: 238
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<html><head>
|
||
<title>301 Moved Permanently</title>
|
||
</head><body>
|
||
<h1>Moved Permanently</h1>
|
||
<p>The document has moved <a href="http://127.0.0.1:8000/testdir/">here</a>.</p>
|
||
|
||
</body></html></pre>
|
||
|
||
<p>Most of the browser will follow up with another request to "<code>/testdir/</code>". For example, If you issue <code>http://127.0.0.1:8000/testdir</code> without the trailing "<code>/</code>" from a browser, you could notice that a trailing "<code>/</code>" was added to the address after the response was given. The morale of the story is: you should include the "<code>/</code>" for directory request to save you an additional GET request. </p>
|
||
|
||
<h4>Issue a GET Request through a Proxy Server</h4>
|
||
|
||
<p>To send a GET request through a proxy server, (a) establish a TCP connection to the proxy server; (b) use an absolute request-URI <code>http://<em>hostname</em>:<em>port</em>/<em>path</em>/<em>fileName</em></code> to the target server.</p>
|
||
|
||
<p>The following trace was captured using telnet. A connection is established with the proxy server, and a GET request issued. Absolute request-URI is used in the request line.</p>
|
||
|
||
<pre class="code-command">GET <strong>http://www.amazon.com/index.html</strong> HTTP/1.1
|
||
Host: www.amazon.com
|
||
Connection: Close
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 302 Found
|
||
Transfer-Encoding: chunked
|
||
Date: Fri, 27 Feb 2004 09:27:35 GMT
|
||
Content-Type: text/html; charset=iso-8859-1
|
||
Connection: close
|
||
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
|
||
Set-Cookie: skin=; domain=.amazon.com; path=/; expires=Wed, 01-Aug-01 12:00:00 GMT
|
||
Connection: close
|
||
Location: http://www.amazon.com:80/exec/obidos/subst/home/home.html
|
||
Via: 1.1 xproxy (NetCache NetApp/5.3.1R4D5)
|
||
|
||
ed
|
||
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
||
<HTML><HEAD>
|
||
<TITLE>302 Found</TITLE>
|
||
</HEAD><BODY>
|
||
<H1>Found</H1>
|
||
The document has moved
|
||
<A HREF="http://www.amazon.com:80/exec/obidos/subst/home/home.html">
|
||
here</A>.<P>
|
||
</BODY></HTML>
|
||
|
||
0
|
||
</pre>
|
||
|
||
<p>Take note that the response is returned in "chunks".</p>
|
||
|
||
|
||
<h3>"HEAD" Request Method</h3>
|
||
|
||
<p>HEAD request is similar to GET request. However, the server returns only the response header without the response body, which contains the actual document. HEAD request is useful for checking the headers, such as <code>Last-Modified</code>, <code>Content-Type</code>, <code>Content-Length</code>, before sending a proper GET request to retrieve the document.</p>
|
||
|
||
<p>The syntax of the HEAD request is as follows:</p>
|
||
|
||
<pre class="code-syntax">HEAD <em>request-URI</em> <em>HTTP-version
|
||
</em>(other optional request headers)
|
||
(blank line)
|
||
(optional request body)</pre>
|
||
|
||
<h5>Example</h5>
|
||
|
||
<pre class="code-command"><strong>HEAD</strong> /index.html HTTP/1.0
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Sun, 18 Oct 2009 14:09:16 GMT
|
||
Server: Apache/2.2.14 (Win32)
|
||
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
|
||
ETag: "10000000565a5-2c-3e94b66c2e680"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 44
|
||
Connection: close
|
||
Content-Type: text/html
|
||
X-Pad: avoid browser bug</pre>
|
||
|
||
<p>Notice that the response consists of the header only without the body, which contains the actual document.</p>
|
||
|
||
<h3>"OPTIONS" Request Method</h3>
|
||
<p>A client can use an OPTIONS request method to query the server which request methods are supported. The syntax for OPTIONS request message is:</p>
|
||
|
||
<pre class="code-syntax">OPTIONS <em>request-URI</em>|* <em>HTTP-version
|
||
</em>(other optional headers)
|
||
(blank line)</pre>
|
||
|
||
<p>"<code>*</code>" can be used in place of a <em>request-URI</em> to indicate that the request does not apply to any particular resource.</p>
|
||
|
||
<h5>Example</h5>
|
||
<p>For example, the following OPTIONS request is sent through a proxy server:</p>
|
||
|
||
<pre class="code-command">OPTIONS http://www.amazon.com/ HTTP/1.1
|
||
Host: www.amazon.com
|
||
Connection: Close
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Fri, 27 Feb 2004 09:42:46 GMT
|
||
Content-Length: 0
|
||
Connection: close
|
||
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
|
||
Allow: GET, HEAD, POST, OPTIONS, TRACE
|
||
Connection: close
|
||
Via: 1.1 xproxy (NetCache NetApp/5.3.1R4D5)
|
||
(blank line)</pre>
|
||
|
||
<p>All servers that allow GET request will allow HEAD request. Sometimes, HEAD is not listed.</p>
|
||
|
||
<h3>"TRACE" Request Method</h3>
|
||
<p>A client can send a TRACE request to ask the server to return a diagnostic trace.</p>
|
||
|
||
<p>TRACE request takes the following syntax:</p>
|
||
|
||
<pre class="code-syntax">TRACE / <em>HTTP-version
|
||
</em>(blank line)</pre>
|
||
|
||
<h5>Example</h5>
|
||
|
||
<p>The following example shows a TRACE request issued through a proxy server.</p>
|
||
|
||
<pre class="code-command">TRACE http://www.amazon.com/ HTTP/1.1
|
||
Host: www.amazon.com
|
||
Connection: Close
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Transfer-Encoding: chunked
|
||
Date: Fri, 27 Feb 2004 09:44:21 GMT
|
||
Content-Type: message/http
|
||
Connection: close
|
||
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
|
||
Connection: close
|
||
Via: 1.1 xproxy (NetCache NetApp/5.3.1R4D5)
|
||
|
||
9d
|
||
TRACE / HTTP/1.1
|
||
Connection: keep-alive
|
||
Host: www.amazon.com
|
||
Via: 1.1 xproxy (NetCache NetApp/5.3.1R4D5)
|
||
X-Forwarded-For: 155.69.185.59, 155.69.5.234
|
||
|
||
0
|
||
</pre>
|
||
|
||
<p>(To compare the TRACE request with trace route)</p>
|
||
|
||
<h3>Submitting HTML Form Data and Query String</h3>
|
||
|
||
<p>In many Internet applications, such as e-commerce and search engine, the clients are required to submit additional information to the server (e.g., the name, address, the search keywords). Based on the data submitted, the server takes an appropriate action and produces a customized response.</p>
|
||
|
||
<p>The clients are usually presented with a form (produced using HTML <code><form></code> tag). Once they fill in the requested data and hit the submit button, the browser packs the form data and submits them to the server, using either a GET request or a POST request.</p>
|
||
|
||
<p>The following is a sample HTML form, which is produced by the following HTML script:</p>
|
||
|
||
<pre class="code-listing"><html>
|
||
<head><title>A Sample HTML Form</title></head>
|
||
<body>
|
||
<h2 align="left">A Sample HTML Data Entry Form</h2>
|
||
<form method="get" action="/bin/process">
|
||
Enter your name: <input type="text" name="username"><br />
|
||
Enter your password: <input type="password" name="password"><br />
|
||
Which year?
|
||
<input type="radio" name="year" value="2" />Yr 1
|
||
<input type="radio" name="year" value="2" />Yr 2
|
||
<input type="radio" name="year" value="3" />Yr 3<br />
|
||
Subject registered:
|
||
<input type="checkbox" name="subject" value="e101" />E101
|
||
<input type="checkbox" name="subject" value="e102" />E102
|
||
<input type="checkbox" name="subject" value="e103" />E103<br />
|
||
Select Day:
|
||
<select name="day">
|
||
<option value="mon">Monday</option>
|
||
<option value="wed">Wednesday</option>
|
||
<option value="fri">Friday</option>
|
||
</select><br />
|
||
<textarea rows="3" cols="30">Enter your special request here</textarea><br />
|
||
<input type="submit" value="SEND" />
|
||
<input type="reset" value="CLEAR" />
|
||
<input type="hidden" name="action" value="registration" />
|
||
</form>
|
||
</body>
|
||
</html></pre>
|
||
|
||
<img class="image-left" src="images/HTML_SampleForm.png" border="1" />
|
||
|
||
<p>A form contains fields. The types of field include:</p>
|
||
<ul>
|
||
<li>Text Box: produced by <code><input type="text"></code>.</li>
|
||
<li>Password Box: produced by <code><input type="password"></code>.</li>
|
||
<li>Radio Button: produced by <code><input type="radio"></code>.</li>
|
||
<li>Checkbox: produced by <code><input type="checkbox"></code>.</li>
|
||
<li>Selection: produced by <code><select></code> and <code><option></code>.</li>
|
||
<li>Text Area: produced by <code><textarea></code>.</li>
|
||
<li>Submit Button: produced by <code><input type="submit"></code>.</li>
|
||
<li>Reset Button: produced by <code><input type="reset"></code>.</li>
|
||
<li>Hidden Field: produced by <code><input type="hidden"></code>.</li>
|
||
<li>Button: produced by <code><input type="button"></code>.</li>
|
||
</ul>
|
||
|
||
<p>Each field has a <em>name</em> and can take on a specified <em>value</em>. Once the client fills in the fields and hits the submit button, the browser gathers each of the fields' name and value, packed them into "<code>name=value</code>" pairs, and concatenates all the fields together using "<code>&</code>" as the field separator. This is known as a <em>query string</em>. It will send the query string to the server as part of the request.</p>
|
||
|
||
<pre class="code-syntax"><em>name1</em>=<em>value1</em><strong>&</strong><em>name2</em>=<em>value2</em><strong>&</strong><em>name3</em>=<em>value3</em><strong>&</strong>...</pre>
|
||
|
||
<p>Special characters are not allowed inside the query string. They must be replaced by a "<code>%</code>" followed by the ASCII code in Hex. E.g., "<code>~</code>" is replaced by "<code>%7E</code>", "<code>#</code>" by "<code>%23</code>" and so on. Since blank is rather common, it can be replaced by either "<code>%20</code>" or "<code>+</code>" (the "<code>+</code>" character must be replaced by "<code>%2B</code>"). This replacement process is called <em>URL-encoding</em>, and the result is a <em>URL-encoded query string</em>. For example, suppose that there are 3 fields inside a form, with name/value of "name=Peter Lee", "address=#123 Happy Ave" and "language=C++", the URL-encoded query string is:</p>
|
||
|
||
<pre class="code-example">name=Peter+Lee<strong>&</strong>address=%23123+Happy+Ave<strong>&</strong>Language=C%2B%2B</pre>
|
||
|
||
<p>The query string can be sent to the server using either HTTP GET or POST request method, which is specified in the <code><form></code>'s attribute "<code>method</code>".</p>
|
||
|
||
<pre class="code-syntax"><form method="<span class="underline">get</span>|post" action="<em>url</em>"></pre>
|
||
|
||
<p>If GET request method is used, the URL-encoded query string will be <em>appended</em> behind the <em>request-URI</em> after a "<code>?</code>" character, i.e.,</p>
|
||
|
||
<pre class="code-syntax">GET <em>request-URI</em><strong>?<em>query-string</em></strong> <em>HTTP-version</em>
|
||
(other optional request headers)
|
||
(blank line)
|
||
(optional request body)</pre>
|
||
|
||
<p>Using GET request to send the query string has the following drawbacks:</p>
|
||
<ul>
|
||
<li>The amount of data you could append behind <em>request-URI</em> is limited. If this amount exceed a server-specific threshold, the server would return an error "414 Request URI too Large".</li>
|
||
<li>The URL-encoded query string would appear on the address box of the browser.</li>
|
||
</ul>
|
||
|
||
<p>POST method overcomes these drawbacks. If POST request method is used, the query string will be sent in the body of the request message, where the amount is not limited. The request headers <code>Content-Type</code> and <code>Content-Length</code> are used to notify the server the type and the length of the query string. The query string will not appear on the browser’s address box. POST method will be discussed later.</p>
|
||
|
||
<h5>Example</h5>
|
||
|
||
<p>The following HTML form is used to gather the username and password in a login menu.</p>
|
||
|
||
<pre class="code-example"><html>
|
||
<head><title>Login</title></head>
|
||
<body>
|
||
<h2>LOGIN</h2>
|
||
<form method="get" action="/bin/login">
|
||
Username: <input type="text" name="user" size="25" /><br />
|
||
Password: <input type="password" name="pw" size="10" /><br /><br />
|
||
<input type="hidden" name="action" value="login" />
|
||
<input type="submit" value="SEND" />
|
||
</form>
|
||
</body>
|
||
</html></pre>
|
||
|
||
<img class="image-left" src="images/HTML_LoginForm.png" border="1" />
|
||
|
||
<p>The HTTP GET request method is used to send the query string. Suppose the user enters "Peter Lee" as the username, "123456" as password; and clicks the submit button. The following GET request is:</p>
|
||
|
||
<pre class="code-example">GET /bin/login?user=Peter+Lee&pw=123456&action=login HTTP/1.1
|
||
Accept: image/gif, image/jpeg, */*
|
||
Referer: http://127.0.0.1:8000/login.html
|
||
Accept-Language: en-us
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
Host: 127.0.0.1:8000
|
||
Connection: Keep-Alive
|
||
</pre>
|
||
|
||
<p>Note that although the password that you enter does not show on the screen, it is shown clearly in the address box of the browser. You should never use send your password without proper encryption.</p>
|
||
|
||
<pre class="code-example">http://127.0.0.1:8000/bin/login?user=Peter+Lee&pw=123456&action=login</pre>
|
||
|
||
<h3>URL and URI</h3>
|
||
|
||
<h5>URL (Uniform Resource Locator)</h5>
|
||
|
||
<p>A URL (Uniform Resource Locator), defined in RFC 2396, is used to uniquely identify a resource over the web. URL has the following syntax:</p>
|
||
|
||
<pre class="code-syntax"><em>protocol</em>://<em>hostname</em>:<em>port</em>/<em>path-and-file-name</em></pre>
|
||
|
||
<p>There are 4 parts in a URL:</p>
|
||
<ol>
|
||
<li><em>Protocol</em>: The application-layer protocol used by the client and server, e.g., HTTP, FTP, and telnet.</li>
|
||
<li><em>Hostname</em>: The DNS domain name (e.g., www.nowhere123.com) or IP address (e.g., 192.128.1.2) of the server.</li>
|
||
<li><em>Port</em>: The TCP port number that the server is listening for incoming requests from the clients.</li>
|
||
<li><em>Path-and-file-name</em>: The name and location of the requested resource, under the server document base directory.</li>
|
||
</ol>
|
||
|
||
<p>For example, in the URL <code>http://www.nowhere123.com/docs/index.html</code>, the communication protocol is HTTP; the hostname is www.nowhere123.com. The port number was not specified in the URL, and takes on the default number, which is TCP port 80 for HTTP [STD 2]. The path and file name for the resource to be located is "<code>/docs/index.html</code>".</p>
|
||
|
||
<p>Other examples of URL are:</p>
|
||
<pre class="code-example">
|
||
ftp://www.ftp.org/docs/test.txt
|
||
mailto:user@test101.com
|
||
news:soc.culture.Singapore
|
||
telnet://www.nowhere123.com/</pre>
|
||
|
||
<h5>Encoded URL</h5>
|
||
<p>URL cannot contain special characters, such as blank or <code>'~'</code>. Special characters are encoded, in the form of <code>%xx</code>, where xx is the ASCII hex code. For example, <code>'~'</code> is encoded as <code>%7e</code>; <code>'+'</code> is encoded as <code>%2b</code>. A blank can be encoded as <code>%20</code> or <code>'+'</code>. The URL after encoding is called <em>encoded URL</em>.</p>
|
||
|
||
<h5>URI (Uniform Resource Identifier)</h5>
|
||
|
||
<p>URI (Uniform Resource Identifier), defined in RFC3986, is more general than URL, which can even locate a <em>fragment</em> within a resource. The URI syntax for HTTP protocol is:</p>
|
||
|
||
<pre class="code-syntax">http://host:port/path?request-parameters#nameAnchor</pre>
|
||
|
||
<ul>
|
||
<li>The request parameters, in the form of name=value pairs, are separated from the URL by a <code>'?'</code>. The name=value pairs are separated by a <code>'&'</code>.</li>
|
||
<li>The <code>#nameAnchor</code> identifies a fragment within the HTML document, defined via the anchor tag <code><a name="<em>anchorName</em>">...</a></code>.</li>
|
||
<li>URL rewriting for session management, e.g., "<code>...;sessionID=xxxxxx</code>".</li>
|
||
</ul>
|
||
|
||
<h3>"POST" Request Method</h3>
|
||
|
||
<p>POST request method is used to "post" additional data up to the server (e.g., submitting HTML form data or uploading a file). Issuing an HTTP URL from the browser always triggers a GET request. To trigger a POST request, you can use an HTML form with attribute <code>method="post"</code> or write your own network program. For submitting HTML form data, POST request is the same as the GET request except that the URL-encoded query string is sent in the request body, rather than appended behind the <em>request-URI</em>.</p>
|
||
<p> The POST request takes the following syntax:</p>
|
||
|
||
<pre class="code-syntax"><strong>POST</strong> <em>request-URI</em> <em>HTTP-version
|
||
</em>Content-Type: <em>mime-type</em>
|
||
Content-Length: <em>number-of-bytes</em>
|
||
(other optional request headers)
|
||
|
||
(URL-encoded query string)</pre>
|
||
|
||
<p>Request headers <code>Content-Type</code> and <code>Content-Length</code> is necessary in the POST request to inform the server the media type and the length of the request body.</p>
|
||
|
||
<h5>Example: Submitting Form Data using POST Request Method</h5>
|
||
|
||
<p>We use the same HTML script as above, but change the request method to POST.</p>
|
||
|
||
<pre class="code-example"><html>
|
||
<head><title>Login</title></head>
|
||
<body>
|
||
<h2>LOGIN</h2>
|
||
<form <strong>method="post"</strong> action="/bin/login">
|
||
Username: <input type="text" name="user" size="25" /><br />
|
||
Password: <input type="password" name="pw" size="10" /><br /><br />
|
||
<input type="hidden" name="action" value="login" />
|
||
<input type="submit" value="SEND" />
|
||
</form>
|
||
</body>
|
||
</html></pre>
|
||
|
||
<p>Suppose the user enters "Peter Lee" as username and "123456" as password, and clicks the submit button, the following POST request would be generated by the browser:</p>
|
||
|
||
<pre class="code-example"><strong>POST /bin/login</strong> HTTP/1.1
|
||
Host: 127.0.0.1:8000
|
||
Accept: image/gif, image/jpeg, */*
|
||
Referer: http://127.0.0.1:8000/login.html
|
||
Accept-Language: en-us
|
||
<strong>Content-Type: application/x-www-form-urlencoded</strong>
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
<strong>Content-Length: 37</strong>
|
||
Connection: Keep-Alive
|
||
Cache-Control: no-cache
|
||
|
||
<strong>User=Peter+Lee&pw=123456&action=login</strong></pre>
|
||
|
||
<p>Note that the <code>Content-Type</code> header informs the server the data is URL-encoded (with a special MIME type <code>application/x-www-form-urlencoded</code>), and the <code>Content-Length</code> header tells the server how many bytes to read from the message body.</p>
|
||
|
||
<h5>POST vs GET for Submitting Form Data</h5>
|
||
|
||
<p>As mentioned in the previous section, POST request has the following advantage compared with the GET request in sending the query string:</p>
|
||
<ul>
|
||
<li>The amount of data that can be posted is unlimited, as they are kept in the request body, which is often sent to the server in a separate data stream.</li>
|
||
<li>The query string is not shown on the address box of the browser.</li>
|
||
</ul>
|
||
|
||
<p>Note that although the password is not shown on the browser’s address box, it is transmitted to the server in clear text, and subjected to network sniffing. Hence, sending password using a POST request is absolutely not secure.</p>
|
||
|
||
<h3>File Upload using <code>multipart/form-data</code> POST Request<a name="FileUpload"> </a></h3>
|
||
|
||
<p>"RFC 1867: Form-based File upload in HTML" specifies how a file can be uploaded to the server using a POST request from an HTML form. A new attribute <code>type="file"</code> was added to the <code><input></code> tag of HTML <code><form></code> to support file upload. The file-upload POST data is not URL-encoded (in the standard <code>application/x-www-form-urlencoded</code>), but uses a new MIME type of <code>multipart/form-data</code>.</p>
|
||
|
||
<h5>Example</h5>
|
||
<p>The following HTML form can be used for file upload:</p>
|
||
<pre class="code-example"><html>
|
||
<head><title>File Upload</title></head>
|
||
<body>
|
||
<h2>Upload File</h2>
|
||
<form <strong>method="post" enctype="multipart/form-data"</strong> action="servlet/UploadServlet">
|
||
Who are you: <input type="text" name="username" /><br />
|
||
Choose the file to upload:
|
||
<strong><input type="file" name="fileID" /></strong><br />
|
||
<input type="submit" value="SEND" />
|
||
</form>
|
||
</body>
|
||
</html></pre>
|
||
|
||
<img class="image-left" src="images/HTML_FileUploadForm.png" border="1" />
|
||
|
||
<p>When the browser encountered an <code><input></code> tag with attribute <code>type="file"</code>, it displays a text box and a "browse..." button, to allow user to choose the file to be uploaded.</p>
|
||
|
||
<p>When the user clicks the submit button, the browser send the form data and the content of the selected file(s). The old encoding type "<code>application/x-www-form-urlencoded</code>" is inefficient for sending binary data and non-ASCII characters. A new media type "<code>multipart/form-data</code>" is used instead.</p>
|
||
|
||
<p>Each part identifies the input name within the original HTML form, and the content type if the media is known, or as <code>application/octet-stream</code> otherwise.</p>
|
||
|
||
<p>The original local file name could be supplied as a "<code>filename</code>" parameter, or in the "<code>Content-Disposition: form-data</code>" header.</p>
|
||
|
||
<p>An example of the POST message for file upload is as follows:</p>
|
||
|
||
<pre class="code-example">POST /bin/upload HTTP/1.1
|
||
Host: test101
|
||
Accept: image/gif, image/jpeg, */*
|
||
Accept-Language: en-us
|
||
<strong>Content-Type: multipart/form-data; boundary=---------------------------7d41b838504d8</strong>
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
Content-Length: 342
|
||
Connection: Keep-Alive
|
||
Cache-Control: no-cache
|
||
|
||
-----------------------------7d41b838504d8 <strong>Content-Disposition: form-data; name="username"</strong>
|
||
Peter Lee
|
||
-----------------------------7d41b838504d8 <strong>Content-Disposition: form-data; name="fileID"; filename="C:\temp.html" Content-Type: text/plain</strong>
|
||
<h1>Home page on main server</h1>
|
||
-----------------------------7d41b838504d8--</pre>
|
||
|
||
<p>Servlet 3.0 provides built-in support for processing file upload. Read "<a href="https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaServletCaseStudyPart2.html#FileUpload">Uploading Files in Servlet 3.0</a>".</p>
|
||
|
||
<h3>"CONNECT" Request Method</h3>
|
||
|
||
<p>The HTTP CONNECT request is used to ask a proxy to make a connection to anther host and simply relay the content, rather than attempting to parse or cache the message. This is often used to make a connection through a proxy.</p>
|
||
|
||
<p>(Under Construction)</p>
|
||
|
||
<h3>Other Request Methods</h3>
|
||
|
||
<p>PUT: Ask the server to store the data.</p>
|
||
|
||
<p>DELETE: Ask the server to delete the data.</p>
|
||
|
||
<p>For security consideration, PUT and DELETE are not supported by most of the production server.</p>
|
||
|
||
<p>Extension methods (also error codes and headers) can be defined to extend the functionality of the HTTP protocol.</p>
|
||
|
||
<p>(Under Construction)</p>
|
||
|
||
<h3>Content Negotiation</h3>
|
||
|
||
<p>As mention earlier, HTTP support content negotiation between the client and the server. A client can use additional request headers (such as <code>Accept</code>, <code>Accept-Language</code>, <code>Accept-Charset</code>, <code>Accept-Encoding</code>) to tell the server what it can handle or which content it prefers. If the server possesses multiple versions of the same document in different format, it will return the format that the client prefers. This process is called <em>content negotiation</em>.</p>
|
||
|
||
<h4>Content-Type Negotiation</h4>
|
||
<p>The server uses a MIME configuration file (called "<code>conf\mime.types</code>") to map the <em>file extension</em> to a <em>media type</em>, so that it can ascertain the media type of the file by looking at its file extension. For example, file extensions "<code>.htm</code>", "<code>.html</code>" are associated with MIME media type "<code>text/html</code>", file extension of "<code>.jpg</code>", "<code>.jpeg</code>" are associated with "<code>image/jpeg</code>". When a file is returned to the client, the server has to put up a <code>Content-Type</code> response header to inform the client the media type of the data.</p>
|
||
|
||
<p>For content-type negotiation, suppose that the client requests for a file call "<code>logo</code>" without specifying its type, and sends an header "<code>Accept: image/gif, image/jpeg,...</code>". If the server has 2 formats of the "<code>logo</code>": "<code>logo.gif</code>" and "<code>logo.jpg</code>", and the MIME configuration file have the following entries:</p>
|
||
|
||
<pre class="code-syntax">image/gif gif
|
||
image/jpeg jpeg jpg jpe</pre>
|
||
|
||
<p>The server will return "<code>logo.gif</code>" to the client, based on the client <code>Accept</code> header, and the MIME type/file mapping. The server will include a "<code>Content-type: image/gif</code>" header in its response.</p>
|
||
|
||
<p>The message trace is shown:</p>
|
||
|
||
<pre class="code-command">GET /logo HTTP/1.1
|
||
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
|
||
application/x-shockwave-flash, application/vnd.ms-excel,
|
||
application/vnd.ms-powerpoint, application/msword, */*
|
||
Accept-Language: en-us
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
Host: test101:8080
|
||
Connection: Keep-Alive
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Sun, 29 Feb 2004 01:42:22 GMT
|
||
Server: Apache/1.3.29 (Win32)
|
||
Content-Location: logo.gif
|
||
Vary: negotiate,accept
|
||
TCN: choice
|
||
Last-Modified: Wed, 21 Feb 1996 19:45:52 GMT
|
||
ETag: "0-916-312b7670;404142de"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 2326
|
||
Keep-Alive: timeout=15, max=100
|
||
Connection: Keep-Alive
|
||
Content-Type: image/gif
|
||
(blank line)
|
||
(body omitted)</pre>
|
||
|
||
<p>However, if the server has 3 "<code>logo.*</code>" files, "<code>logo.gif</code>", "<code>logo.html</code>", "<code>logo.jpg</code>", and "<code>Accept: */*</code>" was used:</p>
|
||
|
||
<pre class="code-command">GET /logo HTTP/1.1
|
||
Accept: */*
|
||
Accept-Language: en-us
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
Host: test101:8080
|
||
Connection: Keep-Alive
|
||
(blank line)</pre>
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Sun, 29 Feb 2004 01:48:16 GMT
|
||
Server: Apache/1.3.29 (Win32)
|
||
Content-Location: logo.html
|
||
Vary: negotiate,accept
|
||
TCN: choice
|
||
Last-Modified: Fri, 20 Feb 2004 04:31:17 GMT
|
||
ETag: "0-10-40358d95;404144c1"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 16
|
||
Keep-Alive: timeout=15, max=100
|
||
Connection: Keep-Alive
|
||
Content-Type: text/html
|
||
(blank line)
|
||
(body omitted)</pre>
|
||
|
||
<pre class="code-example">Accept: */*</pre>
|
||
|
||
<p>The following Apache’s configuration directives are relevant to content-type negotiation:</p>
|
||
|
||
<ul>
|
||
|
||
<li>The <code>TypeConfig</code> directive can be used to specify the location of the MIME mapping file:
|
||
<pre class="code-example">TypeConfig conf/mime.types</pre>
|
||
</li>
|
||
|
||
<li>The <code>AddType</code> directive can be used to include additional MIME type mapping in the configuration file:
|
||
<pre class="code-example">AddType <em>mime-type</em> <em>extension1</em> [<em>extension2</em>]</pre>
|
||
</li>
|
||
|
||
<li>The <code>DefaultType</code> directive gives the MIME type of an unknown file extension (in the <code>Content-Type</code> response header)
|
||
|
||
<pre class="code-example">DefaultType text/plain
|
||
</pre>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Language Negotiation and "Options MultiView"</h4>
|
||
|
||
<p>The "<code>Options MultiView</code>" directive is the simpler way to implement language negotiation. For Example:</p>
|
||
<pre class="code-example">AddLanguage en .en
|
||
<Directory "C:/_javabin/Apache1.3.29/htdocs">
|
||
Options Indexes MultiViews
|
||
</Directory></pre>
|
||
|
||
<p>Suppose that the client requests for "<code>index.html</code>" and send an "<code>Accept-Language: en-us</code>". If the server has "<code>test.html</code>", "<code>test.html.en</code>" and "<code>test.html.cn</code>", based on the client’s preference, "<code>test.html.en</code>" will be returned. ("<code>en</code>" includes "<code>en-us</code>".)</p>
|
||
|
||
<p>A message trace is as follows:</p>
|
||
|
||
<pre class="code-command">GET /index.html HTTP/1.1
|
||
Accept: */*
|
||
Accept-Language: en-us
|
||
Accept-Encoding: gzip, deflate
|
||
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
|
||
Host: test101:8080
|
||
Connection: Keep-Alive
|
||
(blank line)</pre>
|
||
|
||
<pre class="code-output">HTTP/1.1 200 OK
|
||
Date: Sun, 29 Feb 2004 02:08:29 GMT
|
||
Server: Apache/1.3.29 (Win32)
|
||
Content-Location: index.html.en
|
||
Vary: negotiate
|
||
TCN: choice
|
||
Last-Modified: Sun, 29 Feb 2004 02:07:45 GMT
|
||
ETag: "0-13-40414971;40414964"
|
||
Accept-Ranges: bytes
|
||
Content-Length: 19
|
||
Keep-Alive: timeout=15, max=100
|
||
Connection: Keep-Alive
|
||
Content-Type: text/html
|
||
Content-Language: en
|
||
(blank line)
|
||
(body omitted)</pre>
|
||
|
||
<p>The <code>AddLanguage</code> directive is needed to associate a language code with a file extension, similar to MIME type/file mapping.</p>
|
||
|
||
<p>Note that "<code>Options All</code>" directive does not include "<code>MultiViews</code>" option. That is, you have to explicitly turn on MultiViews.</p>
|
||
|
||
<p>The directive <code>LanguagePriority</code> can be used to specify the language preference in case of a tie during content negotiation or if the client does not express a preference. For example:</p>
|
||
|
||
<pre class="code-example"><IfModule mod_negotiation.c>
|
||
LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br
|
||
</IfModule></pre>
|
||
|
||
<h4>Character Set Negotiation</h4>
|
||
<p>A client can use the request header <code>Accept-Charset</code> to negotiate with the server for the character set it prefers.</p>
|
||
|
||
<pre class="code-syntax">Accept-Charset: <em>charset-1</em>, <em>charset-2</em>, ...</pre>
|
||
|
||
<p>The commonly encountered character sets include: ISO-8859-1 (Latin-I), ISO-8859-2, ISO-8859-5, BIG5 (Chinese Traditional), GB2312 (Chinese Simplified), UCS2 (2-byte Unicode), UCS4 (4-byte Unicode), UTF8 (Encoded Unicode), and etc.</p>
|
||
|
||
<p>Similarly, the <code>AddCharset</code> directive is used to associate the file extension with the character set. For example:</p>
|
||
|
||
<pre class="code-example">AddCharset ISO-8859-8 .iso8859-8
|
||
AddCharset ISO-2022-JP .jis
|
||
AddCharset Big5 .Big5 .big5
|
||
AddCharset WINDOWS-1251 .cp-1251
|
||
AddCharset CP866 .cp866
|
||
AddCharset ISO-8859-5 .iso-ru
|
||
AddCharset KOI8-R .koi8-r
|
||
AddCharset UCS-2 .ucs2
|
||
AddCharset UCS-4 .ucs4
|
||
AddCharset UTF-8 .utf8</pre>
|
||
|
||
<h4>Encoding Negotiation</h4>
|
||
<p>A client can use the <code>Accept-Encoding</code> header to tell the server the type of encoding it supports. The common encoding schemes are: "<code>x-gzip (.gz, .tgz)</code>" and "<code>x-compress (.Z)</code>".</p>
|
||
|
||
<pre class="code-syntax">Accept-Encoding: <em>encoding-method-1</em>, <em>encoding-method-2</em>, ...</pre>
|
||
|
||
<p>Similarly, the <code>AddEncoding</code> directive is used to associate the file extension with the an encoding scheme. For example:</p>
|
||
|
||
<pre class="code-example">AddEncoding x-compress .Z
|
||
AddEncoding x-gzip .gz .tgz</pre>
|
||
|
||
<h3>Persistent (or Keep-alive) Connections</h3>
|
||
|
||
<p>In HTTP/1.0, the server closes the TCP connection after delivering the response by default (<code>Connection: Close</code>). That is, each TCP connection services only one request. This is not efficiency as many HTML pages contain hyperlinks (via <code><a href="url"></code> tag) to other resources (such as images, scripts – either locally or from a remote server). If you download a page containing 5 inline images, the browser has to establish TCP connection 6 times to the same server.</p>
|
||
|
||
<p>The client can negotiate with the server and ask the server not to close the connection after delivering the response, so that another request can be sent through the same connection. This is known as persistent connection (or keep-alive connection). Persistent connections greatly enhance the efficiency of the network. For HTTP/1.0, the default connection is non-persistent. To ask for persistent connection, the client must include a request header "<code>Connection: Keep-alive</code>" in the request message to negotiate with the server.</p>
|
||
|
||
<p>For HTTP/1.1, the default connection is persistent. The client do not have to sent the "<code>Connection: Keep-alive</code>" header. Instead, the client may wish to send the header "<code>Connection: Close</code>" to ask the server to close the connection after delivering the response.</p>
|
||
|
||
<p>Persistent connection is extremely useful for web pages with many small inline images and other associated data, as all these can be downloaded using the same connection. The benefits for persistent connection are:</p>
|
||
|
||
<ul>
|
||
<li>CPU time and resource saving in opening and closing TCP connection in client, proxy, gateways, and the origin server.</li>
|
||
<li>Request can be "pipelined". That is, a client can make several requests without waiting for each response, so as to use the network more efficiently.</li>
|
||
<li>Faster response as no time needed to perform TCP’s connection opening handshaking.</li>
|
||
</ul>
|
||
|
||
<p>In Apache HTTP server, several configuration directives are related to the persistent connections:</p>
|
||
|
||
<p>The <code>KeepAlive</code> directive decides whether to support persistent connections. This takes value of either On or Off.</p>
|
||
<pre class="code-syntax">KeepAlive On|Off</pre>
|
||
|
||
<p>The <code>MaxKeepAliveRequests</code> directive sets the maximum number of requests that can be sent through a persistent connection. You can set to 0 to allow unlimited number of requests. It is recommended to set to a high number for better performance and network efficiency.</p>
|
||
|
||
<pre class="code-syntax">MaxKeepAliveRequests 200</pre>
|
||
|
||
<p>The <code>KeepAliveTimeOut</code> directive set the time out in seconds for a persistent connection to wait for the next request.</p>
|
||
<pre class="code-syntax">KeepAliveTimeout 10</pre>
|
||
|
||
<h3>Range Download</h3>
|
||
|
||
<pre class="code-syntax">Accept-Ranges: bytes
|
||
Transfer-Encoding: chunked</pre>
|
||
|
||
<p>(Under Construction)</p>
|
||
|
||
<h3>Cache Control</h3>
|
||
<p>The client can send a request header "<code>Cache-control: no-cache</code>" to tell the proxy to get a fresh copy from the original server, even thought there is a local cached copy. Unfortunately, HTTP/1.0 server does not understand this header, but uses an older request header "<code>Pragma: no-cache</code>". You could include both headers in your request.</p>
|
||
|
||
<pre class="code-syntax">Pragma: no-cache
|
||
Cache-Control: no-cache</pre>
|
||
|
||
<p>(More, Under Construction)</p>
|
||
<p> </p>
|
||
<h4>REFERENCES & RESOURCES</h4>
|
||
<ul>
|
||
<li>W3C HTTP specifications at <a href="http://www.w3.org/standards/techs/http">http://www.w3.org/standards/techs/http</a>.</li>
|
||
<li>RFC 2616 "Hypertext Transfer Protocol HTTP/1.1", 1999 @ <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.</li>
|
||
<li>RFC 1945 "Hypertext Transfer Protocol HTTP/1.0", 1996 @ <a href="http://www.ietf.org/rfc/rfc1945.txt">http://www.ietf.org/rfc/rfc1945.txt</a>. </li>
|
||
<li>STD 2: "Assigned numbers", 1994.</li>
|
||
<li>STD 5: "Internet Protocol (IP)", 1981.</li>
|
||
<li>STD 6: "User Datagram Protocol (UDP)", 1980.</li>
|
||
<li>STD 7: "Transmission Control Protocol (TCP)", 1983.</li>
|
||
<li>RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax", 1998.</li>
|
||
<li>RFC 2045: "Multipurpose Internet Mail Extension (MIME) Part 1: Format of Internet Message Bodies", 1996.</li>
|
||
<li>RFC 1867: "Form-based File upload in HTML", 1995, (obsoleted by RFC2854).</li>
|
||
<li>RFC 2854: "The text/html media type", 2000.</li>
|
||
<li>Mutlipart Servlet for file upload @ <a href="http://www.servlets.com/">www.servlets.com</a></li></ul>
|
||
|
||
<p class="p-last-modified">Latest version tested: HTTP 1.1, Apache HTTP Server 2.2.14<br />
|
||
Last modified: October 20, 2009</p>
|
||
|
||
</div> <!-- End the content division -->
|
||
|
||
<!-- print footer -->
|
||
<script type="text/javascript" src="../scripts/footer.js"></script>
|
||
</div> <!-- End the container division -->
|
||
</body>
|
||
</html>
|