suricata/doc/userguide/rules/http-keywords.rst

HTTP Keywords
=============

.. role:: example-rule-action
.. role:: example-rule-header
.. role:: example-rule-options
.. role:: example-rule-emphasis

Using the HTTP specific sticky buffers (see :ref:`rules-modifiers`) provides a
way to efficiently inspect the specific fields of HTTP protocol communications.
After specifying a sticky buffer in a rule it should be followed by one or
more :doc:`payload-keywords` or using :ref:`pcre`.

HTTP Primer
-----------
HTTP is considered a client-server or request-response protocol. A client
requests resources from a server and a server responds to the request.

In versions of HTTP prior to version 2 a client request could look like:

Example HTTP Request::

  GET /index.html HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

Example signature that would alert on the above request.

.. container:: example-rule

  alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP Request Example"; \
  flow:established,to_server; :example-rule-options:`http.method; \
  content:"GET"; http.uri; content:"/index.html"; bsize:11; http.protocol; \
  content:"HTTP/1.1"; bsize:8; http.user_agent; content:"Mozilla/5.0"; bsize:11; \
  http.host; content:"suricata.io"; bsize:11;` classtype:bad-unknown; sid:25; rev:1;)

In versions of HTTP prior to version 2 a server response could look like:

Example HTTP Response::

  HTTP/1.1 200 OK
  Content-Type: text/html
  Content-Length: 258
  Date: Thu, 14 Dec 2023 20:22:41 GMT
  Server: nginx/0.8.54
  Connection: Close

Example signature that would alert on the above response.

.. container:: example-rule

  alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"HTTP Stat Code Example"; \
  flow:established,to_client; :example-rule-options:`http.stat_code; \
  content:"200"; bsize:8; http.content_type; content:"text/html"; bsize:9;` \
  classtype:bad-unknown; sid:30; rev:1;)

Request Keywords:
 * :ref:`http.uri`
 * :ref:`http.uri.raw`
 * :ref:`http.method`
 * :ref:`http.request_line`
 * :ref:`http.request_body`
 * :ref:`http.user_agent`
 * :ref:`http.host`
 * :ref:`http.accept`
 * :ref:`http.accept_lang`
 * :ref:`http.accept_enc`
 * :ref:`http.referer`
 * :ref:`file.name`

Response Keywords:
 * :ref:`http.stat_msg`
 * :ref:`http.stat_code`
 * :ref:`http.response_line`
 * :ref:`http.response_body`
 * :ref:`http.server`
 * :ref:`http.location`

Request or Response Keywords:
 * :ref:`file.data`
 * :ref:`http.content_type`
 * :ref:`http.content_len`
 * :ref:`http.start`
 * :ref:`http.protocol`
 * :ref:`http.header_names`
 * :ref:`http.header`
 * :ref:`http.cookie`

Although cookies are sent in an HTTP header, you can not match on them
with the ``http.header`` keyword. Cookies are matched with their own
keyword, namely ``http.cookie``.

Each part of the table belongs to a so-called *buffer*. The HTTP
method belongs to the method buffer, HTTP headers to the header buffer
etc. A buffer is a specific portion of the request or response that
Suricata extracts in memory for inspection.

All previous described keywords can be used in combination with a
buffer in a signature. The keywords ``distance`` and ``within`` are
relative modifiers, so they may only be used within the same
buffer. You can not relate content matches against different buffers
with relative modifiers.

.. _http.method:

http.method
-----------

The ``http.method`` keyword matches on the method/verb used in an HTTP request.
HTTP request methods can be any of the following:

* GET
* POST
* HEAD
* OPTIONS
* PUT
* DELETE
* TRACE
* CONNECT
* PATCH

It is possible to use any of the :doc:`payload-keywords` with the ``http.method`` keyword.

Example HTTP Request::

  GET /index.html HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

.. container:: example-rule

  alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP Request Example"; \
  flow:established,to_server; :example-rule-options:`http.method; \
  content:"GET";` classtype:bad-unknown; sid:2; rev:1;)

.. _rules-http-uri-normalization:

.. _http.uri:

http.uri 
--------

Matching on the HTTP URI buffer has two options in Suricata, the ``http.uri``
and the ``http.uri.raw`` sticky buffers.

It is possible to use any of the :doc:`payload-keywords` with the ``http.uri``
keywords.

The ``http.uri`` keyword normalizes the URI buffer. For example, if a URI has two
leading ``//``, Suricata will normalize the URI to a single leading ``/``.

Normalization Example::

  GET //index.html HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

In this case :example-rule-emphasis:`//index.html` would be normalized to 
:example-rule-emphasis:`/index.html`.

Normalized HTTP Request Example::

  GET /index.html HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

.. container:: example-rule

  alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP URI Example"; \
  flow:established,to_server; :example-rule-options:`http.uri; \
  content:"/index.html";` bsize:11; classtype:bad-unknown; sid:3; rev:1;)

.. _http.uri.raw:

http.uri.raw
------------

The ``http.uri.raw`` buffer matches on HTTP URI content but does not
have any normalization performed on the buffer contents.
(see :ref:`rules-http-uri-normalization`)

Abnormal HTTP Request Example::

  GET //index.html HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

.. container:: example-rule

  alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP URI Raw Example"; \
  flow:established,to_server; :example-rule-options:`http.uri.raw; \
  content:"//index.html";` bsize:12; classtype:bad-unknown; sid:4; rev:1;)

.. note:: The ``http.uri.raw`` keyword/buffer does not allow for spaces.

Example Request::

  GET /example spaces HTTP/1.1
  User-Agent: Mozilla/5.0
  Host: suricata.io

``http.uri.raw`` would be populated with :example-rule-header:`/example`

:ref:`http.protocol` would be populated with :example-rule-header:`spaces HTTP/1.1`

Reference: `https://redmine.openinfosecfoundation.org/issues/2881 <https://redmine.openinfosecfoundation.org/issues/2881>`_

.. _urilen:

urilen
------

The ``urilen`` keyword is used to match on the length of the request
URI. It is possible to use the ``<`` and ``>`` operators, which
indicate respectively *smaller than* and *larger than*.

urilen uses an :ref:`unsigned 64-bit integer <rules-integer-keywords>`.

The format of ``urilen`` is::

  urilen:3;

Other possibilities are::

  urilen:1;
  urilen:>1;
  urilen:<10;
  urilen:10<>20;	(bigger than 10, smaller than 20)

Example:


Example of ``urilen`` in a signature:

.. container:: example-rule

    alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Possible Vundo Trojan Variant reporting to Controller"; flow:established,to_server; content:"POST "; depth:5; uricontent:"/frame.html?"; :example-rule-emphasis:`urilen: > 80;` classtype:trojan-activity; reference:url,doc.emergingthreats.net/2009173; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Vundo; sid:2009173; rev:2;)

You can also append ``norm`` or ``raw`` to define what sort of buffer you want
to use (normalized or raw buffer).

.. _http.protocol:

http.protocol
-------------

The ``http.protocol`` inspects the protocol field from the HTTP request or
response line. If the request line is 'GET / HTTP/1.0\r\n', then this buffer
will contain 'HTTP/1.0'.

Example::

    alert http any any -> any any (flow:to_server; http.protocol; content:"HTTP/1.0"; sid:1;)

``http.protocol`` replaces the previous keyword name: ```http_protocol``. You may continue to use the previous name, but it's recommended that rules be converted to use the new name.

Example::

    alert http any any -> any any (flow:to_server; http.protocol; content:"HTTP/1.0"; sid:1;)

.. _http.request_line:

http.request_line
-----------------

The ``http.request_line`` forces the whole HTTP request line to be inspected.

Example::

    alert http any any -> any any (http.request_line; content:"GET / HTTP/1.0"; sid:1;)

.. _http.header:

.. _http.header.raw:

http.header and http.header.raw
-------------------------------

With the ``http.header`` sticky buffer, it is possible to match
specifically and only on the HTTP header buffer. This contains all of
the extracted headers in a single buffer, except for those indicated
in the documentation that are not able to match by this buffer and
have their own sticky buffer (e.g. ``http.cookie``). The sticky buffer
can be used in combination with all previously mentioned content
modifiers, like ``depth``, ``distance``, ``offset``, ``nocase`` and
``within``.

    **Note**: the header buffer is *normalized*. Any trailing
    whitespace and tab characters are removed. See:
    https://lists.openinfosecfoundation.org/pipermail/oisf-users/2011-October/000935.html.
    If there are multiple values for the same header name, they are
    concatenated with a comma and space (", ") between each of them.
    See RFC 2616 4.2 Message Headers.
    To avoid that, use the ``http.header.raw`` keyword.

Example of a header in a HTTP request:



Example of the purpose of ``http.header``:

.. _http.cookie:

http.cookie
-----------

With the ``http.cookie`` sticky buffer it is possible to match
specifically on the HTTP cookie contents. Keywords like ``depth``,
``distance``, ``offset``, ``nocase`` and ``within`` can be used
with ``http.cookie``.

Note that cookies are passed in HTTP headers but Suricata extracts
the cookie data to ``http.cookie`` and will not match cookie content
put in the ``http.header`` sticky buffer.

Example of a cookie in a HTTP request:

Examples::

    GET / HTTP/1.1
    User-Agent: Mozilla/5.0
    Host: www.example.com
    Cookie: PHPSESSIONID=1234
    Connection: close

Example ``http.cookie`` keyword in a signature:

.. container:: example-rule

    alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP Request
    with Cookie"; flow:established,to_server; http.method; content:"GET";
    http.uri; content:"/"; fast_pattern; :example-rule-emphasis:`http.cookie;
    content:"PHPSESSIONID="; startswith;` classtype:bad-unknown; sid:123;
    rev:1;)

.. _http.user_agent:

http.user_agent
---------------

The ``http.user_agent`` sticky buffer is part of the HTTP request
header. It makes it possible to match specifically on the value of the
User-Agent header. It is normalized in the sense that it does not
include the _"User-Agent: "_ header name and separator, nor does it
contain the trailing carriage return and line feed (CRLF). The keyword
can be used in combination with all previously mentioned content
modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and
``within``. Note that the ``pcre`` keyword can also inspect this
buffer when using the ``/V`` modifier.

Normalization: leading spaces **are not** part of this buffer. So
"User-Agent: \r\n" will result in an empty ``http.user_agent`` buffer.

Example of the User-Agent header in a HTTP request:


Example of the purpose of ``http.user_agent``:


Notes
~~~~~

-  The ``http.user_agent`` buffer will NOT include the header name,
   colon, or leading whitespace.  i.e. it will not include
   "User-Agent: ".

-  The ``http.user_agent`` buffer does not include a CRLF (0x0D
   0x0A) at the end.  If you want to match the end of the buffer, use a
   relative ``isdataat`` or a PCRE (although PCRE will be worse on
   performance).

-  If a request contains multiple "User-Agent" headers, the values will
   be concatenated in the ``http.user_agent`` buffer, in the order
   seen from top to bottom, with a comma and space (", ") between each
   of them.

   Example request::

          GET /test.html HTTP/1.1
          User-Agent: SuriTester/0.8
          User-Agent: GGGG

   ``http.user_agent`` buffer contents::

          SuriTester/0.8, GGGG

-  Corresponding PCRE modifier: ``V``

-  Using the ``http.user_agent`` buffer is more efficient when it
   comes to performance than using the ``http.header`` buffer (~10%
   better).

-  `https://blog.inliniac.net/2012/07/09/suricata-http\_user\_agent-vs-http\_header/ <https://blog.inliniac.net/2012/07/09/suricata-http_user_agent-vs-http_header/>`_

.. _http.accept:

http.accept
-----------

Sticky buffer to match on the HTTP Accept header. Only contains the header
value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (http.accept; content:"image/gif"; sid:1;)

.. _http.accept_enc:

http.accept_enc
---------------

Sticky buffer to match on the HTTP Accept-Encoding header. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (http.accept_enc; content:"gzip"; sid:1;)

.. _http.accept_lang:

http.accept_lang
----------------

Sticky buffer to match on the HTTP Accept-Language header. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (http.accept_lang; content:"en-us"; sid:1;)

.. _http.connection:

http.connection
---------------

Sticky buffer to match on the HTTP Connection header. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (http.connection; content:"keep-alive"; sid:1;)

.. _http.content_type:

http.content_type
-----------------

Sticky buffer to match on the HTTP Content-Type headers. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Use flow:to_server or flow:to_client to force inspection of request or response.

Examples::

    alert http any any -> any any (flow:to_server; \
            http.content_type; content:"x-www-form-urlencoded"; sid:1;)

    alert http any any -> any any (flow:to_client; \
            http.content_type; content:"text/javascript"; sid:2;)

.. _http.content_len:

http.content_len
----------------

Sticky buffer to match on the HTTP Content-Length headers. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Use flow:to_server or flow:to_client to force inspection of request or response.

Examples::

    alert http any any -> any any (flow:to_server; \
            http.content_len; content:"666"; sid:1;)

    alert http any any -> any any (flow:to_client; \
            http.content_len; content:"555"; sid:2;)

To do a numeric inspection of the content length, ``byte_test`` can be used.

Example, match if C-L is equal to or bigger than 8079::

    alert http any any -> any any (flow:to_client; \
            http.content_len; byte_test:0,>=,8079,0,string,dec; sid:3;)

.. _http.referer:

http.referer
---------------

Sticky buffer to match on the HTTP Referer header. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (http.referer; content:".php"; sid:1;)

.. _http.start:

http.start
----------

Inspect the start of a HTTP request or response. This will contain the
request/response line plus the request/response headers. Use flow:to_server
or flow:to_client to force inspection of request or response.

Example::

    alert http any any -> any any (http.start; content:"HTTP/1.1|0d 0a|User-Agent"; sid:1;)

The buffer contains the normalized headers and is terminated by an extra
\\r\\n to indicate the end of the headers.

.. _http.header_names:

http.header_names
-----------------

Inspect a buffer only containing the names of the HTTP headers. Useful
for making sure a header is not present or testing for a certain order
of headers.

Buffer starts with a \\r\\n and ends with an extra \\r\\n.

Example buffer::

    \\r\\nHost\\r\\n\\r\\n

Example rule::

    alert http any any -> any any (http.header_names; content:"|0d 0a|Host|0d 0a|"; sid:1;)

Example to make sure *only* Host is present::

    alert http any any -> any any (http.header_names; \
            content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)

Example to make sure *User-Agent* is directly after *Host*::

    alert http any any -> any any (http.header_names; \
            content:"|0d 0a|Host|0d 0a|User-Agent|0d 0a|"; sid:1;)

Example to make sure *User-Agent* is after *Host*, but not necessarily directly after::

    alert http any any -> any any (http.header_names; \
            content:"|0d 0a|Host|0d 0a|"; content:"|0a 0d|User-Agent|0d 0a|"; \
            distance:-2; sid:1;)

.. _http.request_body:

http.request_body
-----------------

With the ``http.request_body`` sticky buffer, it is possible to
match specifically and only on the HTTP request body. The keyword can
be used in combination with all previously mentioned content modifiers
like ``distance``, ``offset``, ``nocase``, ``within``, etc.

Example of ``http.request_body`` in a HTTP request:


Example of the purpose of ``http.client_body``:

Note: how much of the request/client body is inspected is controlled
in the :ref:`libhtp configuration section
<suricata-yaml-configure-libhtp>` via the ``request-body-limit``
setting.

``http.request_body`` replaces the previous keyword name: ```http_client_body``. You may continue
+to use the previous name, but it's recommended that rules be converted to use
+the new name.

.. _http.stat_code:

http.stat_code
--------------

With the ``http.stat_code`` sticky buffer, it is possible to match
specifically and only on the HTTP status code buffer. The keyword can
be used in combination with all previously mentioned content modifiers
like ``distance``, ``offset``, ``nocase``, ``within``, etc.

Example of ``http.stat_code`` in a HTTP response:


Example of the purpose of ``http.stat_code``:

.. _http.stat_msg:

http.stat_msg
-------------

With the ``http.stat_msg`` sticky buffer, it is possible to match
specifically and only on the HTTP status message buffer. The keyword
can be used in combination with all previously mentioned content
modifiers like ``depth``, ``distance``, ``offset``, ``nocase`` and
``within``.

Example of ``http.stat_msg`` in a HTTP response:

Example of the purpose of ``http.stat_msg``:

.. _http.response_line:

http.response_line
------------------

The ``http.response_line`` forces the whole HTTP response line to be inspected.

Example::

    alert http any any -> any any (http.response_line; content:"HTTP/1.0 200 OK"; sid:1;)

.. _http.response_body:

http.response_body
------------------

With the ``http.response_body`` sticky buffer, it is possible to
match specifically and only on the HTTP response body. The keyword can
be used in combination with all previously mentioned content modifiers
like ``distance``, ``offset``, ``nocase``, ``within``, etc.

Note: how much of the response/server body is inspected is controlled
in your :ref:`libhtp configuration section
<suricata-yaml-configure-libhtp>` via the ``response-body-limit``
setting.

Notes
~~~~~

-  Using ``http.response_body`` is similar to having content matches
   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.

-  Since ``http.response_body`` matches on a server response, it
   can't be used with the ``to_server`` or ``from_client`` flow
   directives.

-  Corresponding PCRE modifier: ``Q``

-  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
+the new name.

.. _http.server:

http.server
-----------

Sticky buffer to match on the HTTP Server headers. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (flow:to_client; \
            http.server; content:"Microsoft-IIS/6.0"; sid:1;)

.. _http.location:

http.location
-------------

Sticky buffer to match on the HTTP Location headers. Only contains the
header value. The \\r\\n after the header are not part of the buffer.

Example::

    alert http any any -> any any (flow:to_client; \
            http.location; content:"http://www.google.com"; sid:1;)

.. _http.host:

.. _http.host.raw:

http.host and http.host.raw
---------------------------

With the ``http.host`` sticky buffer, it is possible to
match specifically and only the normalized hostname.
The ``http.host.raw`` inspects the raw hostname.

The keyword can be used in combination with most of the content modifiers
like ``distance``, ``offset``, ``within``, etc.

The ``nocase`` keyword is not allowed anymore. Keep in mind that you need
to specify a lowercase pattern.

.. _http.request_header:

http.request_header
-------------------

Match on the name and value of a HTTP request header (HTTP1 or HTTP2).

For HTTP2, name and value get concatenated by ": ", colon and space.
To detect if a http2 header name contains ':',
the keyword ``http2.header_name`` can be used.

Examples::

  http.request_header; content:"agent: nghttp2";
  http.request_header; content:"custom-header: I love::colons";

``http.request_header`` is a 'sticky buffer'.

``http.request_header`` can be used as ``fast_pattern``.

.. _http.response_header:

http.response_header
--------------------

Match on the name and value of a HTTP response header (HTTP1 or HTTP2).

For HTTP2, name and value get concatenated by ": ", colon and space.
To detect if a http2 header name contains ':',
the keyword ``http2.header_name`` can be used.

Examples::

  http.response_header; content:"server: nghttp2";
  http.response_header; content:"custom-header: I love::colons";

``http.response_header`` is a 'sticky buffer'.

``http.response_header`` can be used as ``fast_pattern``.

Notes
~~~~~

-  ``http.host`` does not contain the port associated with
   the host (i.e. abc.com:1234). To match on the host and port
   or negate a host and port use ``http.host.raw``.

-  The ``http.host`` and ``http.host.raw`` buffers are populated
   from either the URI (if the full URI is present in the request like
   in a proxy request) or the HTTP Host header. If both are present, the
   URI is used.

-  The ``http.host`` and ``http.host.raw`` buffers will NOT
   include the header name, colon, or leading whitespace if populated
   from the Host header.  i.e. they will not include "Host: ".

-  The ``http.host`` and ``http.host.raw`` buffers do not
   include a CRLF (0x0D 0x0A) at the end.  If you want to match the end
   of the buffer, use a relative 'isdataat' or a PCRE (although PCRE
   will be worse on performance).

-  The ``http.host`` buffer is normalized to be all lower case.

-  The content match that ``http.host`` applies to must be all lower
   case or have the ``nocase`` flag set.

-  ``http.host.raw`` matches the unnormalized buffer so matching
   will be case-sensitive (unless ``nocase`` is set).

-  If a request contains multiple "Host" headers, the values will be
   concatenated in the ``http.host`` and ``http.host.raw``
   buffers, in the order seen from top to bottom, with a comma and space
   (", ") between each of them.

   Example request::

          GET /test.html HTTP/1.1
          Host: ABC.com
          Accept: */*
          Host: efg.net

   ``http.host`` buffer contents::

          abc.com, efg.net

   ``http.host.raw`` buffer contents::

          ABC.com, efg.net

-  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.
``file.data`` also works for HTTP request body and can be used in other
protocols than HTTP1.

Example::

  alert http any any -> any any (file.data; content:"abc"; content:"xyz";)


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
content match individually.

As the body of a HTTP response can be very large, it is inspected in
smaller chunks.

How much of the response/server body is inspected is controlled
in your :ref:`libhtp configuration section
<suricata-yaml-configure-libhtp>` via the ``response-body-limit``
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.
Flash decompression must be enabled under ``libhtp`` configuration:

::

    # Decompress SWF files.
    # 2 types: 'deflate', 'lzma', 'both' will decompress deflate and lzma
    # compress-depth:
    # Specifies the maximum amount of data to decompress,
    # set 0 for unlimited.
    # decompress-depth:
    # Specifies the maximum amount of decompressed data to obtain,
    # set 0 for unlimited.
    swf-decompression:
      enabled: yes
      type: both
      compress-depth: 0
      decompress-depth: 0

Notes
~~~~~

-  file.data is the preferred notation, however, file_data is still
   recognized by the engine and works as well.

-  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.
   'content:!"<html";' could not match on the first chunk, but would
   then possibly match on the 2nd. To avoid this, use a depth setting.
   The depth setting takes the body size into account.
   Assuming that the ``response-body-minimal-inspect-size`` is bigger
   than 1k, 'content:!"<html"; depth:1024;' can only match if the
   pattern '<html' is absent from the first inspected chunk.

-  Refer to :doc:`file-keywords` for additional information.

Multiple Buffer Matching
~~~~~~~~~~~~~~~~~~~~~~~~

``file.data`` supports multiple buffer matching, see :doc:`multi-buffer-matching`.

.. _file.name:

file.name
---------

The ``file.name`` keyword can be used at the HTTP application level.

Example::

  alert http any any -> any any (msg:"http layer file.name keyword usage"; \
  file.name; content:"picture.jpg"; classtype:bad-unknown; sid:1; rev:1;)

For additional information on the ``file.name`` keyword, see :doc:`file-keywords`.