In the third-generation engine syntax, we can use pre-filtering keywords to modify the detection item with the most obvious threat characteristics. This item is used as the pre-filtered item for preferential matching in the subsequent detection process. Two pre-filtering keywords are supported: **fast_pattern** and **fast_value** (**fast_value** will be described in detail in a later section). A maximum of four detection items in a signature can be modified by the pre-filtering keyword (**fast_pattern**/**fast_value**). When the user does not specify **fast_pattern** in a signature, the third-generation engine automatically specifies the longest feature string in the detection item as the pre-filtering string.

Generally, the signature writer should select the longest-possible string with the most obvious threat characteristics as **fast_pattern**. An example is as follows:

> GET /index.php?keyword=shellcodeString HTTP/1.1

In the above example, assume that the **shellcodeString** part is a malicious attack string. When writing a signature, the signature writer can select **shellcodeString** as **fast_pattern**. If the **index.php** part (which is common also in normal traffic) is used as **fast_pattern**, a large amount of non-malicious traffic is matched during pre-filtering. Proper selection of **fast_pattern** will bring a better performance and accuracy experience.

The signature can be written as follows:
```
flow: from_client, message; content:"shellcodeString"; http_uri; fast_pattern;
  ```

Note that the shortest **fast_pattern** string supported by the third-generation engine contains 3 bytes.

fast_pattern Keyword