1.Function Introduction

On National Proxy System, Individual Control policy rules determine whether to allow, block, redirect or replace a session based on traffic attributes, such as URL, request header fields, request body keywords, response header fields, response body keywords, IP address, Subscribe ID and their combination. You could specify these attributes in the submenu of Control Policy.

2.Action

You could select one of the five actions for above attributes, as known as:
  • Monitor：the Proxy produce a log to record matched HTTP session information.
  • Block:the Proxy terminate matched HTTP session with an error page and produce a log. You MUST specify a Response Code and a Response Content to generate an error page.
  • Redirect: the Proxy redirect matched HTTP session to a predefined URL. Since redirection need to be performed before delivering response to client, condition of response body is not applicable in this action. You MUST configure the redirect response via Response Code and Response URL. The Response URL MUST start with a scheme (http:// or https://). You SHOULD NOT select 301 as Response Code unless you exactly know what you are doing. This action produces a log.
  • Replace:the Proxy Searches in a given HTTP part to Find a given string, and Replace any matches with another given string. If no match was found, the session remained untouched. For performance concerns, condition of request body and response body is not available in this action. For example, you can configure the Proxy to search in the response body of URL “www.example.com/index.html”, find every “string1” and replace with “string2”. This action produces a log.
  • Whitelist:the Proxy pass-through the matched sessions and produce no log.
  • In case of HTTP session matches one more policies, the priority order is Whitelist > Reject > Redirect > Replace > Monitor, action with higher priority overrides others.

3.Attibutes

The attributes are detailed in following context:
  • URL：From proxy’s perspective, a HTTP URL consists of a hierarchical sequence of three components: URL = hostname/path[?query] . The URL path name can also be specified by the user in the local writing system. If not already encoded, it is converted to UTF-8, and any characters not part of the basic URL character set are escaped as hexadecimal using percent-encoding; for example, search keywords “русский” in Google produces URL： https://www.google.com/search?q=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9 To perform policy action on above URL, you could input the whole URL in the input box. Or, you could input original keywords and let the Proxy do the decoding, e.g. “google.com/search” & “русский”. Note that the scheme string MUST be excluded from the URL, it’s “https://” in this case.
  • Request Header: is used to set conditions on request header fields. Header fields are colon-separated key-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. For example, “user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)“ is a header filed in request header. The Matching District is used to configure the field’s key, if the key was presented, the Proxy will search in the value for Keywords.
  • Response Header： is used to set conditions on response header fields. Its configuration is similar to Request Header.
  • Request Body：is used to set conditions on request’s body message. The Proxy searches the pre-configured Keywords in it. You can configure non-ASCII or non-utf8 keywords by turn on HEX.
  • Response Body：is used to set conditions on response’s body message. Its configuration is similar to Request Body.