📄 695-697.html

📁 linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E
💻 HTML
字号:
<HTML>

<HEAD>

<TITLE>Special Edition Using Linux, Fourth Edition:Configuring Apache</TITLE>

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
        var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>

 -->




<!--ISBN=0789717468//-->

<!--TITLE=Special Edition Using Linux, Fourth Edition//-->

<!--AUTHOR=Jack Tackett//-->

<!--AUTHOR=Jr.//-->

<!--AUTHOR=Steve Burnett//-->

<!--PUBLISHER=Macmillan Computer Publishing//-->

<!--IMPRINT=Que//-->

<!--CHAPTER=36//-->

<!--PAGES=695-697//-->

<!--UNASSIGNED1//-->

<!--UNASSIGNED2//-->



<CENTER>

<TABLE BORDER>

<TR>

<TD><A HREF="693-695.html">Previous</A></TD>

<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>

<TD><A HREF="697-699.html">Next</A></TD>

</TR>

</TABLE>

</CENTER>

<P><BR></P>

<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">Cookies</FONT></H4>

<P>HTTP <I>cookies</I> are a method for maintaining statefulness in a stateless protocol. What does this mean? In HTTP, a session between a client and a server typically spans many separate actual TCP connections, thus making it difficult to tie together accesses into an application that requires state, such as a shopping-cart application. Cookies are a solution to that problem. As implemented by Netscape in its browser and subsequently by many others, servers can assign clients a cookie, meaning some sort of opaque string whose meaning is significant only to the server itself, and then the client can give that cookie back to the server on subsequent requests.</P>

<P>The mod_cookies module nicely handles the details of assigning unique cookies to every visitor, based on the visitor&#146;s host name and a random number. This cookie can be accessed from the CGI environment as the <TT>HTTP_COOKIE</TT> environment variable, for the same reason that all HTTP headers are accessible to CGI applications. The CGI scripts can use this as a key in a session-tracking database, or it can be logged and tallied up to get a good, if undercounted, estimate of the total number of users that visited a site, not just the number of hits or even number of unique domains.</P>

<P>Happily, there are no configuration issues here. Simply compile with mod_cookies and away you go. It couldn&#146;t be easier.</P>

<H4 ALIGN="LEFT"><A NAME="Heading12"></A><FONT COLOR="#000077">Configurable Logging</FONT></H4>

<P>For most folks, the default logfile format (also known as <I>Common Logfile Format</I>, or CLF) doesn&#146;t provide enough information when it comes to doing a serious analysis of the efficacy of your Web site. It provides basic numbers in terms of raw hits, pages accessed, hosts accessing, timestamps, and so forth, but it fails to capture the &#147;referring&#148; URL, the browser being used, and any cookies being used. So there are two ways to get more data for your logfiles: by using the NCSA-compatibility directives for logging certain bits of information to separate browsers or by using Apache&#146;s own totally configurable logfile format.</P>

<P><FONT SIZE="+1"><B>NCSA Compatibility</B></FONT></P>

<P>For compatibility with the NCSA 1.4 Web server, two modules were added. These modules log the <TT>User-Agent</TT> and <TT>Referer</TT> headers from the HTTP request stream.</P>

<P><TT>User-Agent</TT> is the header most browsers send that identifies what software the browser is using. Logging of this header can be activated by an <TT>AgentLog</TT> directive in the srm.conf file or in a virtual-host-specific section. This directive takes one argument, the name of the file to which the user-agents are logged&#151;for example,</P>

<!-- CODE SNIP //-->

<PRE>

AgentLog logs/agent_log

</PRE>

<!-- END CODE SNIP //-->

<P>To use the <TT>AgentLog</TT> directive, you need to ensure that the mod_log_agent module has been compiled and linked to the server.</P>

<P>Similarly, the <TT>Referer</TT> header is sent by the browser to indicate the tail end of a link. In other words, when you&#146;re on a page with an URL of &#147;A,&#148; and there&#146;s a link on that page with an URL of &#147;B,&#148; and you follow that link, the request for page &#147;B&#148; includes a <TT>Referer</TT> header with the URL of &#147;A.&#148; This is very useful for finding what sites link to your site, and what proportion of traffic they account for.</P>

<P>The logging of the <TT>Referer</TT> header is activated by a <TT>RefererLog</TT> directive, which points to the file to which the referers get logged:</P>

<!-- CODE SNIP //-->

<PRE>

RefererLog logs/referer_log

</PRE>

<!-- END CODE SNIP //-->

<P>One other option the <TT>Referer</TT> logging module provides is <TT>RefererIgnore</TT>, a directive that allows you to ignore <TT>Referer</TT> headers. <TT>RefererIgnore</TT> is useful for weeding out the referers from your own site, if all you&#146;re interested in is links to you from other sites. For example, if your site is <A HREF="www.myhost.com">www.myhost.com</A>, you might want to use the following:</P>

<!-- CODE SNIP //-->

<PRE>

RefererIgnore www.myhost.com

</PRE>

<!-- END CODE SNIP //-->

<P>Remember that logging of the <TT>Referer</TT> header requires compiling and linking in mod_log_referer.</P>

<P><FONT SIZE="+1"><B>Totally Configurable Logging</B></FONT></P>

<P>The previous modules were provided, like many Apache features, for backward compatibility. They have some problems, though. Because they don&#146;t contain any other information about the request they&#146;re logging from, it&#146;s nearly impossible to tell which <TT>Referer</TT> fields went to which specific objects on your site. Ideally, all the information about a transaction with the server can be logged into one file, extending the common logfile format or replacing it altogether. Well, such a beast exists in the mod_log_config module.</P>

<P>The mod<TT>_</TT> log<TT>_</TT> config module implements the <TT>LogFormat</TT> directive, which takes as its argument a string, with variables beginning with % to indicate different pieces of data from the request. Table 36.4 lists the variables.</P>

<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>Table 36.4</B> Variables for the <TT>LogFormat</TT> Directive

<TR>

<TH COLSPAN="2"><HR>

<TR>

<TH WIDTH="20%" ALIGN="LEFT">Variable

<TH WIDTH="80%" ALIGN="LEFT">Definition

<TR>

<TH COLSPAN="2"><HR>

<TR>

<TD><TT>%h</TT>

<TD>Remote host.

<TR>

<TD><TT>%l</TT>

<TD>Remote identification via <TT>identd</TT>.

<TR>

<TD VALIGN="TOP"><TT>%u</TT>

<TD>Remote user, as determined by any user authentication that may take place. If the user wasn&#146;t authenticated and the status of the request is a 401 (authorization error), this field may be bogus.

<TR>

<TD><TT>%t</TT>

<TD>Common logfile format for time.

<TR>

<TD><TT>%r</TT>

<TD>First line of request.

<TR>

<TD VALIGN="TOP"><TT>%s</TT>

<TD>Status. For requests that are internally redirected, this is the status of the original request; <TT>%&gt;s</TT> will give the last.

<TR>

<TD><TT>%b</TT>

<TD>Bytes sent.

<TR>

<TD VALIGN="TOP"><TT>%&#123;Foobar&#125;i</TT>

<TD>Contents of <TT>Foobar:</TT> header line(s) in the request from the client to the server.

<TR>

<TD VALIGN="TOP"><TT>%&#123;Foobar&#125;o</TT>

<TD>Contents of <TT>Foobar:</TT> header line(s) in the response from the server to the client.

<TR>

<TD COLSPAN="2"><HR>

</TABLE>

<P><BR></P>

<CENTER>

<TABLE BORDER>

<TR>

<TD><A HREF="693-695.html">Previous</A></TD>

<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>

<TD><A HREF="697-699.html">Next</A></TD>

</TR>

</TABLE>

</CENTER>





</td>
</tr>
</table>

<!-- begin footer information -->





</body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -