This file belongs into
ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
- $Id: faq.sgml,v 1.61.2.19 2002/08/25 23:31:56 hal9 Exp $
+ $Id: faq.sgml,v 2.3 2002/09/13 11:50:55 oes Exp $
Copyright (C) 2001, 2002 Privoxy Developers <developers@privoxy.org>
See LICENSE.
</subscript>
</pubdate>
-<pubdate>$Id: faq.sgml,v 1.61.2.19 2002/08/25 23:31:56 hal9 Exp $</pubdate>
+<pubdate>$Id: faq.sgml,v 2.3 2002/09/13 11:50:55 oes Exp $</pubdate>
<!--
url="../user-manual/config.html#LISTEN-ADDRESS">listen-address</ulink></literal>
option, which may be commented out with a <quote>#</quote> symbol. Make sure
it is uncommented, and assign it the address of the LAN gateway interface,
- and port number to use. Assuming your LAN address is 192.168.1.1 and you
+ and port number to use. Assuming your server's LAN address is 192.168.1.1 and you
wish to run <application>Privoxy</application> on port 8118, this line
should look like:
</para>
all browsers on the network then to use this address and port number.
</para>
+<para>
+ Alternately, you can have <application>Privoxy</application> listen on
+ all available interfaces:
+</para>
+
+<para>
+ <screen>
+ listen-address :8118</screen>
+</para>
+
+<para>
+ And then use <application>Privoxy's</application>
+ <ulink
+ url="../user-manual/config.html#PERMIT-ACCESS">permit-access</ulink>
+ feature to limit connections. A firewall in this situation is recommended
+ as well.
+</para>
+
+<para>
+ The above steps should be the same for any TCP network, regardless of
+ operating system.
+</para>
+
<para>
If you run <application>Privoxy</application> on a LAN with untrusted users,
- we recommend that you double-check the <ulink
+ we recommend that you double-check all <ulink
url="../user-manual/config.html#ACCESS-CONTROL">access control and security</ulink>
options!
</para>
for efficiency reasons, which exposes them to the full power of
<application>Privoxy</application>'s ad blocking.
</para>
+<para>
+ <quote>Content cookies</quote> (those that are embedded in the actual HTML or
+ JS page content, see <literal><ulink
+ url="../user-manual/actions-file.html#FILTER-CONTENT-COOKIES">filter{content-cookies}</ulink></literal>),
+ in an SSL transaction will be impossible to block under these conditions.
+ Fortunately, this does not seem to be a very common scenario since most
+ cookies come by traditional means.
+</para>
</sect2>
-->
</sect2>
+<sect2 renderas="sect3" id="microsuck">
+<title>I've noticed that Privoxy changes <quote>Microsoft</quote> to
+<quote>MicroSuck</quote>! Why are you manipulating my browsing?</title>
+
+<para>
+ We're not. The text substitutions that you are seeing are disabled
+ in the default configuration as shipped. You have either manually
+ activated the <quote><literal>fun</literal></quote> filter which
+ is clearly labeled <quote>Text replacements for subversive browsing
+ fun!</quote> or you have implicitly activated it by choosing the
+ <quote>Advanced</quote> profile in the web-based editor.
+</para>
+</sect2>
+
</sect1>
so do not configure your browser to use <application>Privoxy</application>
as an FTP proxy. The same is true for any protocol other than HTTP or HTTPS.
</para>
+ <para>
+ Most browsers understand FTP as well as HTTP. If you connect to a site, with
+ a URL like <literal>ftp://ftp.example.com</literal>, your browser is making
+ an FTP connection, and not a HTTP connection. So while your browser may
+ speak FTP, <application>Privoxy</application> does not, and cannot proxy
+ such traffic.
+ </para>
</sect2>
<!-- ~~~~~ New section ~~~~~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2 renderas="sect3" id="blankpage">
<title>I get a completely blank page at one site. <quote>View Source</quote>
- shows only: <markup><![CDATA[<html><body></body></html>]]></markup>.</title>
+ shows only: <markup><![CDATA[<html><body></body></html>]]></markup>. Without
+ <application>Privoxy</application> the page loads fine.</title>
<para>
- This is often the result of a webserver using
- <application>PHP</application> that mishandles the request
- <application>Privoxy</application> sends to not compress the content
- (a <application>PHP</application> bug).
+ Chances are that the site suffers from a bug in
+ <ulink url="http://www.php.net/"><application>PHP</application></ulink>,
+ which results in empty pages being sent if the client explicitly requests
+ an uncompressed page, like <application>Privoxy</application> does.
+ This bug has been fixed in PHP 4.2.3.
</para>
<para>
- In a default configuration, <application>Privoxy</application> requests all
- data be sent <quote>uncompressed</quote>. This is required for the page
- filtering and other magic to work. In some rare cases, the browser and
- webserver miscommunicate and the result is a totally blank page. The
- suggested work around is to selectively turn off this feature for sites
- that exhibit such behavior. Example section for <filename>user.action</filename>:
+ To find out if this is in fact the source of the problem, try adding
+ the site to a <literal>-prevent-compression</literal> section in
+ <filename>user.action</filename>:
</para>
<screen>
# Make exceptions for ill-behaved sites:
#
{-prevent-compression}
.example.com</screen>
+ <para>
+ If that works, you may also want to report the problem to the
+ site's webmasters, telling them to use zlib.output_compression
+ instead of ob_gzhandler in their PHP applications (workaround)
+ or upgrade to PHP 4.2.3 or later (fix).
+ </para>
</sect2>
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
$Log: faq.sgml,v $
+Revision 2.3 2002/09/13 11:50:55 oes
+Added MicroSuck topic; Updated PHP bug topic
+
+Revision 2.2 2002/09/05 04:25:05 hal9
+Sync with 3.0 branch. No new content.
+
Revision 1.61.2.19 2002/08/25 23:31:56 hal9
Fix one grammatical error. Add brief FAQ relating to tranparent proxies (ie
port 80 setting). Add FAQ on effects of Privoxy on downloaded files