From: jason taylor <jtfas90@gmail.com>
Date: Tue, 26 Apr 2022 20:49:19 +0000 (+0000)
Subject: doc: update file_data to file.data keyword
X-Git-Tag: suricata-7.0.0-beta1~635
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=83f2056d2024b170ab39e50b4ee47051a20e7411;p=thirdparty%2Fsuricata.git

doc: update file_data to file.data keyword

Signed-off-by: jason taylor <jtfas90@gmail.com>
---

diff --git a/doc/userguide/rules/http-keywords.rst b/doc/userguide/rules/http-keywords.rst
index c3bf4a6a0e..8436a41a76 100644
--- a/doc/userguide/rules/http-keywords.rst
+++ b/doc/userguide/rules/http-keywords.rst
@@ -616,12 +616,12 @@ Notes
 ~~~~~
 
 -  Using ``http.response_body`` is similar to having content matches
-   that come after ``file_data`` except that it doesn't permanently
+   that come after ``file.data`` except that it doesn't permanently
    (unless reset) set the detection pointer to the beginning of the
    server response body. i.e. it is not a sticky buffer.
 
 -  ``http.response_body`` will match on gzip decoded data just like
-   ``file_data`` does.
+   ``file.data`` does.
 
 -  Since ``http.response_body`` matches on a server response, it
    can't be used with the ``to_server`` or ``from_client`` flow
@@ -629,7 +629,7 @@ Notes
 
 -  Corresponding PCRE modifier: ``Q``
 
--  further notes at the ``file_data`` section below.
+-  further notes at the ``file.data`` section below.
 
 ``http.response_body`` replaces the previous keyword name: ```http_server_body``. You may continue
 +to use the previous name, but it's recommended that rules be converted to use
@@ -723,19 +723,19 @@ Notes
 -  Corresponding PCRE modifier (``http_host``): ``W``
 -  Corresponding PCRE modifier (``http_raw_host``): ``Z``
 
-file_data
+file.data
 ---------
 
-With ``file_data``, the HTTP response body is inspected, just like
-with ``http.response_body``. The ``file_data`` keyword is a sticky buffer.
+With ``file.data``, the HTTP response body is inspected, just like
+with ``http.response_body``. The ``file.data`` keyword is a sticky buffer.
 
 Example::
 
-  alert http any any -> any any (file_data; content:"abc"; content:"xyz";)
+  alert http any any -> any any (file.data; content:"abc"; content:"xyz";)
 
 .. image:: http-keywords/file_data.png
 
-The ``file_data`` keyword affects all following content matches, until
+The ``file.data`` keyword affects all following content matches, until
 the ``pkt_data`` keyword is encountered or it reaches the end of the
 rule. This makes it a useful shortcut for applying many content
 matches to the HTTP response body, eliminating the need to modify each
@@ -750,7 +750,7 @@ in your :ref:`libhtp configuration section
 setting.
 
 If the HTTP body is a flash file compressed with 'deflate' or 'lzma',
-it can be decompressed and ``file_data`` can match on the decompress data.
+it can be decompressed and ``file.data`` can match on the decompress data.
 Flash decompression must be enabled under ``libhtp`` configuration:
 
 ::
@@ -772,7 +772,7 @@ Flash decompression must be enabled under ``libhtp`` configuration:
 Notes
 ~~~~~
 
--  If a HTTP body is using gzip or deflate, ``file_data`` will match
+-  If a HTTP body is using gzip or deflate, ``file.data`` will match
    on the decompressed data.
 
 -  Negated matching is affected by the chunked inspection. E.g.
@@ -783,4 +783,4 @@ Notes
    than 1k, 'content:!"<html"; depth:1024;' can only match if the
    pattern '<html' is absent from the first inspected chunk.
 
--  ``file_data`` can also be used with SMTP
+-  ``file.data`` can also be used with SMTP