Specify a name for the filter and optionally add a description.

Select the request methods to match the filter.

The following request methods are supported. You can select one, several or all of them.

Method	Description
GET	Requests a representation of the specified resource.
POST	Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
PUT	Uploads a representation of the specified resource.
HEAD	Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
DELETE	Deletes the specified resource.

Specify the URLs to match the filter.

You can specify URL hosts and/or URL paths. Separate multiple entries by the vertical bar '|'.

Select Host, and type the host name or IP address (including port number, if any) as part of the URL.
Select Path, and type the path part of the URL (if any) after, but not including, the final '/' of the host part, and up to, but not including, the '?' of the query, if any.

This section supports both the (?) and (*) wildcard characters. ? matches any single character while * matches any number of any characters. For example,

Host	Path
`www.example.com` matches www.example.com only.	`example.com/news.htm` matches example.com/news.htm only.
`www.example.c?` matches www.example.co but not www.example.com.	`example.com/news?.htm` matches example.com/news1.htm but not example.com/news11.htm.
`*.example.com` matches jp.example.com and us.example.com.	To match all URLs with the path including news, type `news`.

Specify the header fields and corresponding values to match the filter.

Click the '+' icon in the last column to create an item.
Specify the header field under Header Field Name.
The field name must comply with the HTTP naming standards, for example, User-Agent
Select the operation from the drop-down list and type the values to be used in Value.
This supports both string-value matching and integer-value comparison:
- Contains | Not contain: Means the header field contains or does not contain the keywords using a simple string comparison. Add multiple keywords with an OR relation, separated by the vertical bar '|'.
  
  Wildcard characters (?) and (*) are supported. In this syntax, to treat a wildcard character as a literal character, add an escape character, which is the backslash \, in front of the wildcard character. For example, if you want * to match just *, type \*.
- =, ≠, ≥, ≤: Means integer-value comparison.
- Exist | Not exist: Means whether the header includes or does not include the defined field.
Optionally click the '-' icon in the last column to delete an item.

The web traffic is matched by one filter only if all the defined scopes are matched, which means there is an AND relation among Request Methods, URLs, and Header Fields.

Specify the header fields and corresponding actions to them for the headers of the web traffic that matches the filter.

Note:

Actions apply to only headers of request HTTP messages.

Click the '+' icon in the last column to create an item.
Specify the header field under Header Field Name, for example, X-GoogApps-Allowed-Domains. It can be a standard or non-standard request header field.

Select an action from the drop-down list and type the value to be used in Value.

Add: The specified field, if it exists, will be overwritten with the newly configured value. If it does not exist, the field will be added as a new field into the header.
Delete: The specified field, if it exists, will be deleted from the header. If it does not exist, the action will be ignored.

Note:

TMWS predefines a list of protected header fields that are not allowed to be modified. If the specified header field hits the list, you will be prompted to remove the action item.

The Value area supports a string-value, a token, and a combination of both, for example, Host, %URL%, or URL: %URL%. The following tokens are supported:

Token	Description
%URL%	URL in the HTTP request
%DOMAIN%	Host name of the requested URL
%SERVER_IP%	IP address of the server requested
%POLICY_NAME%	Name of the cloud access rule that the filter is added in
%USER%	User that sends the HTTP request
%USER_GROUP%	Group that the user belongs to
%GATEWAY_NAME%	Location of the TMWS gateway where the HTTP request passes
%URL_CATEGORY%	URL category of the content requested
%APP_CATEGORY%	Application category of the content requested
%MIME_TYPE%	MIME type of the content requested
%FILE_NAME%	Name of the content requested
%TRUE_FILE_TYPE%	True file type of the content requested
%ATP_SECURITY_PROFILE_NAME%	Name of the Threat Protection template triggered
%DLP_SECURITY_PROFILE_NAME%	Name of the Data Loss Prevention profile triggered
%VIRUS_NAME%	Name of the virus detected
%BOTNET_NAME%	Name of the botnet detected
%WRS_SCORE%	WRS Score or the web page requested
%UNSCANNABLE_TYPE_NAME%	Type that a file is unscannable
%CLOUD_SERVICE_FILTER%	Name of the cloud service filter triggered
%CURRENT_VALUE%	Current value of the HTTP header field
%XFF_IP%	Originating IP address of the client that initiates the HTTP request

Optionally click the '-' icon in the last column to delete an item.

All the configured actions will apply to the header of the matched web traffic in the order from top to bottom.

The actions configured in a cloud service filter have to work together with the cloud access rule that the filter is added in to determine the final action on the matched web traffic. For details, see Configuring A Cloud Access Rule.

Click Save.

You can add this filter in cloud access rules as necessary.

Configuring A Cloud Service Filter