offset Keyword
During feature string matching, if the matching is required at a certain offset position, the **offset** keyword can be used to modify **content**. According to the matching start position (offset is 0), two situations are involved: **1**. **content** with the protocol field as a modifier: The start position is the start position of the protocol field. Example: > GET /page1.**<u><font color="red">h</font>tml</u>** > ↑ offset = 7 Matching conditions: ``` content: "html"; http_uri; offset:7; Matched content: "html"; http_uri; offset:8; Not matched In the example URI, the offset 8 is the position of the 't' character. content: "page1"; http_uri; offset:7; Not matched ``` **content** in the preceding rule is modified by the **http_uri** field. The start matching position is the start of the URI field, that is, the position of the backslash. The offset is 0. The substring **html** is complete only when the offset is 7. When the offset is 8, the substring content is **tml**, which cannot match the feature string **html**. Therefore, the second rule cannot be matched. **2**. **content** without a protocol field as the modifier: When no protocol field is used to modify **content**, the content of the TCP/UDP Payload is detected. In this case, check the detection scope of the rule. If the detection scope is session, the start offset position is the start position of the TCP/UDP Payload of the current session. If the detection scope is message, the start offset position is the start position of the TCP/UDP Payload of the current message. Similarly, if the detection scope is packet, the start offset position is the start position of the TCP/UDP Payload of the current packet. Another case is that the **content** rule is modified by the **file_data** keyword. In this case, the file content is detected and the start position is the start position of the single file content.