Determines Squid behavior when encountering strange requests at the
beginning of an accepted TCP connection or the beginning of a bumped
CONNECT tunnel. Controlling Squid reaction to unexpected traffic is
especially useful in interception environments where Squid is likely
to see connections for unsupported protocols that Squid should either
terminate or tunnel at TCP level.
on_unsupported_protocol <action> [!]acl ...
The first matching action wins. Only fast ACLs are supported.
Supported actions are:
tunnel: Establish a TCP connection with the intended server and
blindly shovel TCP packets between the client and server.
respond: Respond with an error message, using the transfer protocol
for the Squid port that received the request (e.g., HTTP
for connections intercepted at the http_port). This is the
default.
Squid expects the following traffic patterns:
http_port: a plain HTTP request
https_port: SSL/TLS handshake followed by an [encrypted] HTTP request
ftp_port: a plain FTP command (no on_unsupported_protocol support yet!)
CONNECT tunnel on http_port: same as https_port
CONNECT tunnel on https_port: same as https_port
Currently, this directive has effect on intercepted connections and
bumped tunnels only. Other cases are not supported because Squid
cannot know the intended destination of other traffic.
For example:
# define what Squid errors indicate receiving non-HTTP traffic:
acl foreignProtocol squid_error ERR_PROTOCOL_UNKNOWN ERR_TOO_BIG
# define what Squid errors indicate receiving nothing:
acl serverTalksFirstProtocol squid_error ERR_REQUEST_START_TIMEOUT
# tunnel everything that does not look like HTTP:
on_unsupported_protocol tunnel foreignProtocol
# tunnel if we think the client waits for the server to talk first:
on_unsupported_protocol tunnel serverTalksFirstProtocol
# in all other error cases, just send an HTTP "error page" response:
on_unsupported_protocol respond all
See also: squid_error ACL