ch02_03.htm

用perl编写CGI的好书。本书从解释CGI和底层HTTP协议如何工作开始

</tr>


<tr>
<td>
<p>Content-Length</p></td>
<td>
<p>Specifies the length (in bytes) of the request content</p></td>
</tr>


<tr>
<td>
<p>Content-Type</p></td>
<td>
<p>Specifies the media type of the request</p></td>
</tr>


<tr>
<td>
<p>
<a name="INDEX-323" />Authentication</p></td>
<td>
<p>Specifies the username and password of the user requesting the
resource</p></td>
</tr>


<tr>
<td>
<p>User-Agent</p></td>
<td>
<p>Specifies the name, version, and platform of the client</p></td>
</tr>


<tr>
<td>
<p>Referer</p></td>
<td>
<p>Specifies the URL that referred the user to the current resource</p></td>
</tr>


<tr>
<td>
<p>Cookie</p></td>
<td>
<p>Returns a name/value pair set by the server on a previous response</p></td>
</tr>



</table>



<a name="ch02-12-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.1. Host</h3>



<p>The <em class="firstterm">Host</em>
<a name="INDEX-324" />
<a name="INDEX-325" /> field is new and is required in HTTP
1.1. The client sends the host name of the web server in this field.
This may sound redundant, since the host should know its own
identity, right? Well, not always. A machine with one IP address may
have multiple <a name="INDEX-326" /> <a name="INDEX-327" />domain names
mapped to it, such as <em class="emphasis">www.oreilly.com</em> and <em class="emphasis">www.ora.com</em>. When a request comes in, it
looks at this header to determine what name the client is referring
to it as, and thus maps the request to the correct content.</p>
</div>





<a name="ch02-13-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.2. Content-Length</h3>



<p>
<a name="INDEX-328" />POST requests include
a content body; in order for the web server to know how much data to
read, it must declare the size of the body in bytes in the
<em class="firstterm">Content-Length</em>
<a name="INDEX-329" /> <a name="INDEX-330" /> field. There are a couple of
circumstances where HTTP 1.1 clients may omit this field, but these
cases don't concern us because the web server will still
calculate this value for us and provide it to our CGI scripts as
though it had been included in the original request. POST requests
that contain empty contents supply a value of
in this header. Requests that do not have a content body, such as GET
and HEAD, omit this field.</p>
</div>





<a name="ch02-14-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.3. Content-Type</h3>



<p>The <em class="firstterm">Content-Type</em> header must always be
provided with requests containing a body. It specifies the media type
of the message. The most common value of this data received from an
HTML form via POST is
<em class="emphasis">application/x-www-form-urlencoded,</em> although
another option for form input (used when submitting files) is
<em class="emphasis">multipart/form-data</em>
<a name="INDEX-331" />
<a name="INDEX-332" />. We'll discuss how to
specify the media type of requests in our discussion of HTML forms in
<a href="ch04_01.htm">Chapter 4, "Forms and CGI"</a>, and we will look at how to parse
multipart requests in <a href="ch05_01.htm">Chapter 5, "CGI.pm"</a>.</p>
</div>





<a name="ch02-23130" /><div class="sect3">
<h3 class="sect3">2.3.2.4. Authorization</h3>



<p>Web servers can require a
<a name="INDEX-333" />
<a name="INDEX-334" />
<a name="INDEX-335" />login for access to
<a name="INDEX-336" />
<a name="INDEX-337" />some resources. If you have ever attempted
to access a restricted area of a web site and been prompted for a
login and password, then you have encountered this form of HTTP
authentication (see <a href="ch02_03.htm#ch02-40524">Figure 2-7</a>).<a href="#FOOTNOTE-3">[3]</a> Note that the login prompt includes text identifying what
you are logging in to; this is the<em class="firstterm">
realm</em>
<a name="INDEX-338" />. Resources that share the same
login are part of the same realm. For most web servers, you assign
resources to a realm by putting them in the same directory and
configuring the web server to assign the directory a name for the
realm along with authorization requirements. For example, if you
wanted to restrict access to URL paths that begin with <em class="emphasis">/protected</em>
<a name="INDEX-339" />
<a name="INDEX-340" />, then you would add the
following to <em class="filename">httpd.conf</em> (or
<em class="filename">access.conf,</em> if you are using it):</p><blockquote>


<a name="FOOTNOTE-3" /><p>[3]The distinction between authentication and authorization is
subtle, but important. <em class="firstterm">Authentication </em>is the
process of identifying someone. <em class="firstterm">Authorization
</em>determines what that person can access.</p>


</blockquote>



<blockquote><pre class="code">&lt;Location /protected&gt;
  AuthType Basic
  AuthName "The Secret Files"
  AuthUserFile  /usr/local/apache/conf/secret.users
  require valid-user
&lt;/Location&gt;</pre></blockquote>



<a name="ch02-40524" /><div class="figure"><img width="274" src="figs/cgi2.0207.gif" height="148" alt="Figure 2-7" /></div><h4 class="objtitle">Figure 2-7. Prompt presented to the user for HTTP authorization</h4>

<p>The user file contains <a name="INDEX-341" />
<a name="INDEX-342" />usernames and encrypted passwords
separated by a colon. You can use the
<tt class="command">htpasswd</tt>
<a name="INDEX-343" /> <a name="INDEX-344" />
utility that comes with Apache to create and update this file; refer
to its manpage or the Apache manual for usage. When the browser
requests a resource in a restricted realm, the server informs the
browser that it requires login information by sending a 401 status
code and the name of the realm in the
<em class="emphasis">WWW-Authenticate</em>
<a name="INDEX-345" /> header (we'll discuss this later
in the chapter). The browser then prompts the user for a username and
password for this realm (if it hasn't done so already) and
resends the request with the credentials in an
<em class="firstterm">Authorization</em> field. There are multiple types
of HTTP authentication, but the only type that is widely supported by
browsers and servers is basic authentication.</p>



<p>The
<em class="emphasis">Authorization</em>
<a name="INDEX-346" /> field for basic authentication looks like
this:</p>



<blockquote><pre class="code">Authorization: Basic dXNlcjpwYXNzd29yZA==</pre></blockquote>



<p>The <a name="INDEX-347" />
<a name="INDEX-348" />encoded portion is simply
the username and password joined with a colon and Base64-encoded.
This can be easily decoded, so basic authentication provides no
security against third parties sniffing usernames and passwords
unless the connection is secured via SSL.</p>



<p>The server handles authentication and authorization transparently for
you. As we will see in the next chapter, you may access the login
name from your CGI scripts but not the password.</p>
</div>





<a name="ch02-15-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.5. User-Agent</h3>



<p>This <a name="INDEX-349" />field
indicates what client the user is using to access the Web. The value
is generally comprised of a nickname of the <a name="INDEX-350" />
<a name="INDEX-351" /> <a name="INDEX-352" />browser, its version number,
and the operating system and platform on which it's running.
Here is an example from Netscape Communicator:</p>



<blockquote><pre class="code">User-Agent: Mozilla/4.5 (Macintosh; I; PPC)</pre></blockquote>



<p>Unfortunately,
<a name="INDEX-353" />Microsoft Internet Explorer made the
dubious decision when it released its browser of also claiming to be
"Mozilla," which is Netscape's nickname. Apparently
this was done because a number of web sites used this field to
distinguish Netscape browsers from others in order to take advantage
of the additional features Netscape offered at the time. Microsoft
made their browser compatible with many of these features and wanted
its users to also take advantage of these enhanced web sites. Even
now, the "Mozilla" moniker remains for the sake of
backward-compatibility. Here is an example from Internet Explorer:</p>



<blockquote><pre class="code">User-Agent: Mozilla/4.0 (compatible; MSIE 4.5; Mac_PowerPC)</pre></blockquote>
</div>





<a name="ch02-16-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.6. Accept</h3>



<p>The <em class="firstterm">Accept</em>
<a name="INDEX-354" /> <a name="INDEX-355" /> field and related fields that begin with
<em class="emphasis">Accept</em>, such as
<em class="firstterm">Accept-Language</em>, are sent by the client to
tell the server the categories of responses it is capable of
understanding. These categories include file formats, languages,
character sets, etc. We discuss this process in more detail later in
this chapter in <a href="ch02_06.htm#ch02-20836">Section 2.6, "Content Negotiation"</a>.</p>
</div>





<a name="ch02-17-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.7. Referer</h3>



<p>No, this is not a typo. Unfortunately, the <em class="firstterm">Referer
</em>
<a name="INDEX-356" />
<a name="INDEX-357" />field was misspelled in the original
protocol and, due to the need to maintain backward-compatibility, we
are stuck with it this way. This field provides the URL of the last
page the user visited, which is generally the page that linked the
user to the requested page:</p>



<blockquote><pre class="code">Referer: http://localhost/index.html</pre></blockquote>



<p>This field is not always sent to the server; browsers provide this
field only when the user generates a request by following a
hyperlink, submitting a form, etc. Browsers don't generally
provide this field when the user manually enters a URL or selects a
bookmark, since these may involve a significant invasion of the
user's privacy.</p>
</div>





<a name="ch02-18-fm2xml" /><div class="sect3">
<h3 class="sect3">2.3.2.8. Cookies</h3>



<p>Web browsers or servers may provide additional headers that are not
part of the HTTP standard. The receiving application should ignore
any <a name="INDEX-358" />
<a name="INDEX-359" />
<a name="INDEX-360" />
<a name="INDEX-361" />headers it
does not recognize. A example of a pair of headers not specified in
the HTTP protocol are <em class="emphasis">Set-Cookie</em> and
<em class="emphasis">Cookie</em>, which Netscape introduced to support
browser cookies. <em class="emphasis">Set-Cookie</em> is sent by the
server as part of a response:</p>



<blockquote><pre class="code">Set-Cookie: cart_id=12345; path=/; expires=Sat, 18-Mar-05 19:06:19 GMT</pre></blockquote>



<p>This header contains data for the client to echo back in the
<em class="emphasis">Cookie</em> header in future requests to that server:</p>



<blockquote><pre class="code">Cookie: cart_id=12345</pre></blockquote>



<p>By assigning different values to each user, servers (and CGI scripts)
can use cookies to differentiate between users. We discuss <a name="INDEX-362" /> <a name="INDEX-363" /> <a name="INDEX-364" />cookies <a name="INDEX-365" /> <a name="INDEX-366" />extensively in <a href="ch11_01.htm">Chapter 11, "Maintaining State"</a>.</p>
</div>
</div>


<hr align="left" width="515" />
<div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch02_02.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm"><img src="../gifs/txthome.gif" alt="Home" border="0" /></a></td><td width="172" valign="top" align="right"><a href="ch02_04.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr><tr><td width="172" valign="top" align="left">2.2. HTTP</td><td width="171" valign="top" align="center"><a href="index/index.htm"><img src="../gifs/index.gif" alt="Book Index" border="0" /></a></td><td width="172" valign="top" align="right">2.4. Server Responses</td></tr></table></div>
<hr align="left" width="515" />

<img src="../gifs/navbar.gif" alt="Library Navigation Links" usemap="#library-map" border="0" />
<p><font size="-1"><a href="copyrght.htm">Copyright &copy; 2001</a> O'Reilly &amp; Associates. All rights reserved.</font></p>

<map name="library-map"><area href="../index.htm" coords="1,1,83,102" shape="rect" /><area href="../lnut/index.htm" coords="81,0,152,95" shape="rect" /><area href="../run/index.htm" coords="172,2,252,105" shape="rect" /><area href="../apache/index.htm" coords="238,2,334,95" shape="rect" /><area href="../sql/index.htm" coords="336,0,412,104" shape="rect" /><area href="../dbi/index.htm" coords="415,0,507,101" shape="rect" /><area href="../cgi/index.htm" coords="511,0,601,99" shape="rect" /></map>

</body></html>