Miscellaneous Options

Miscellaneous Options is just what it sounds like: a hodgepodge of options that don't seem to fit anywhere else. Here you'll find several memory-related options, options regarding headers and user agent settings, and the powerful HTTP accelerator options (Figure 12-18).

Figure 12-18: Miscellaneous Options

Startup DNS test addresses

This should point to a number of hosts that Squid can use to test whether DNS service is working properly on your network. If DNS isn't working properly, Squid will not be able to service requests, so it will refuse to start, with a brief message regarding why in the cache.log. It is recommended that you select two or more host names on the Internet and one or two host names on your intranet, assuming you have one and Squid is expected to service it. By default, the dns_testnames directive checks a few well-known and popular sites: netscape.com, internic.net, nlanr.net, and microsoft.com.

SIGUSR1 logfile rotations

The number of old rotated log files Squid will keep. On Red Hat systems, this option defaults to zero, as logs are rotated via the system standard logrotate program. On other systems, this defaults to 10, which means Squid will keep 10 old log files before overwriting the oldest. This option corresponds to the logfile_rotate directive.

Default domain

The domain that Squid will append to requests that are not possibly fully qualified domain names (more precisely, those that have no dots in them). This option correlates to the append_domain directive.

Error messages text

Provides a means to automatically add some extra information to Squid's error pages. You can add HTML or plain-text comments or links here, which will be added to the error messages displayed to clients. This option correlates to the err_html_text directive.

Per-client statistics?

Allows you to choose whether Squid will keep statistics regarding each individual client. This option configures the client_db directive and defaults to on.

X-Forwarded-For header?

This option allows you to choose whether Squid will report the host name of the system that originally made the request to the origin server. For example, if this option is disabled every request through your cache will be reported as originating from the cache. Usually, this should remain enabled. This correlates to the forwarded_for directive and defaults to on.

Log ICP queries?

Dictates whether Squid will log ICP requests. Disabling this can be a good idea if ICP loads are very high. This option correlates to the log_icp_queries directive and defaults to on.

Minimum direct hops

When using ICMP pinging features of Squid to determine distance to peers and origin servers, this configures when Squid should prefer going direct over a peer. This option requires your Squid to have been compiled with the --enable-icmp, and you must be in a peering relationship with other Squid caches, also with the appropriate build option compiled in. This option correlates to the minimum_direct_hops directive.

Keep memory for future use?

This option turns on memory_pools and allows Squid to keep memory that it has allocated (but no longer needs), so that it will not need to reallocate memory in the future. This can improve performance by a small margin, but may need to be turned off if memory is at a premium on your system. This option defaults to on and should generally be left on, unless you know what you're doing.

Amount of memory to keep

The amount of memory Squid will keep allocated, assuming the Keep memory for future use option is turned on. This option configures the memory_pools_limit directive and defaults to unlimited. Any non-zero value will instruct Squid not to keep more than that amount allocated, and if Squid requires more memory than that to fulfill a request, it will use your system's malloc library. Squid does not preallocate memory, so it is safe to set this reasonably high. If your Squid runs on a dedicated host, it is probably wisest to leave it to its default of unlimited. If it must share the system with other server processes (like Apache or Sendmail) then it might be appropriate to limit it somewhat.

Headers to pass through

Configures the anonymizing features of Squid. This option allows you to dictate what kinds of request headers are allowed to pass through Squid. For example, to prevent origin servers from being able to detect the type of browser your clients are using you would choose to allow all except User-Agent. This option has mostly obscure uses and usually doesn't need to be changed from its default of allowing all headers to pass through. There is a relevant Squid FAQ section [http://www.squid-cache.org/Doc/FAQ/FAQ-4.html#ss4.18] that describes in more detail what can be accomplished with this option. This option corresponds to the anonymize_headers directive and defaults to allow All headers.

Caution 

Indiscriminate use of Squid's anonymizing features can cause websites to behave incorrectly. Because modern websites often rely on the contents of cookies or other headers to know the right JavaScript and HTML code to serve for everything to look and act correctly, many sites could be confused into serving the wrong content or refusing to serve any content to the user.

Fake User-Agent

Acts as an addition to the above option, in that it allows you to configure Squid to report a fake User-Agent header. For example, using this option you could have your Squid report that every client being served is named Mozilla/42.2 (Atari 2600; 8-bit). That would be lying, but perhaps the person looking over the logs at origin servers will find it amusing. If you are using the anonymize headers features to hide your client's User-Agent headers, it is probably wise to include a fake User-Agent header because some servers will not be happy with requests without one. Further, this will cause problems with some web pages for your users, as the User-Agent header is sometimes used to decide which of a number of pages to send based on the features available within a particular browser. The server will usually end up choosing the least interesting page for your clients (e.g., text only, or no JavaScript/Java/etc.).

HTTP Accel Host and Port

The options you will use to configure Squid to act as an accelerator, or as a transparent proxy. When using your Squid as an accelerator, you must configure these two options to point to the IP and port of the web server you are accelerating. If you are using Squid to accelerate a number of virtual hosts, you must choose virtual as the Accel Host. Note that this opens potential security problems, in that your Squid will then be open to users outside of your network as a proxy. This can be avoided via proper firewall rules on your router or on the Squid system itself. Finally, if you are operating your Squid transparently, you would also configure the Accel Host to be virtual and the Accel Port to be 80. Outgoing port 80 traffic will then need to be redirected to your Squid process in order for it to work. This is discussed in much greater detail in the tutorial on transparent proxying. These options configure the httpd_accel_host and httpd_accel_port directives.

HTTP Accel with Proxy

Allows you to operate your cache as both an accelerator and a caching proxy. This option tells Squid to accept both traditional proxy connections and requests intended for an origin web server. This option correlates to the httpd_accel_with_proxy directive.

HTTP Accel Uses Host Header

Configures Squid to use the host header information as described in the HTTP 1.1 specification. This option must be turned on for transparent operation, in order for virtual servers to be cached properly. This option correlates to the httpd_uses_host_header directive.

WCCP Router Address, WCCP Incoming Address, WCCP Outgoing Address

The Web Cache Coordination Protocol is a standard method of implementing an interception proxy. Routers that support WCCP can be configured to direct traffic to one or more web caches using an efficient load balancing mechanism. WCCP also provides for automatic bypassing of an unavailable cache in the event of a failure. Usually, configuring Squid to use WCCP is as simple as configuring it for interception proxying, using the steps discussed later in the Interception Caching tutorial and then entering the address of the router in the WCCP Router Address field. The other two options are very rarely needed, but can be used in some complex network environments where incoming and outgoing data must travel via different routes or from different addresses. These options correspond to the wccp_router, wccp_incoming_address, and wccp_outgoing_address directives and are disabled by default.